TransPyC

0 Fork 0

Files

T

TermiNexus 62cab0f6c1 fix(tpc): 属性取值为空的报文报出"基座 AST 真实形态"（附只读探针反证）

类别：a（编译器缺陷）—— 报文缺事实，且暴露出一个**未触发的 fail-fast**。

现场（TransPyV/App/lib/core/Gen/Expr/ExprGenBase.vp:360，另 231 同族）：
  `v = (ast.Expr*(node)).value` — 同函数前三条 `(ast.Assign/AnnAssign/AugAssign*(node)).value`
  同款写法正常，只有 `ast.Expr` 这条报"赋值表达式 'value'（Attribute 形态）编译期求值为空"。

只读探针（vast.parse + BaseHandle._ExprText/_ExprShape，不跑编译器）反证：
  (ast.Assign*(node)).value  -> Attribute(.value←Call(func=BinOp(BitOr, Attribute(.Assign←…), Attribute(.CPtr←…)),args=1))
  (ast.Expr*(node)).value    -> Attribute(.value←Call(func=BinOp(BitOr, Attribute(.Expr←…),   Attribute(.CPtr←…)),args=1))
  **两者 AST 逐字同形**；且 `_ExprText` 对"Call 基座"会退化成裸 attr 名
  ⇒ 报文里的 `表达式 'value'` 并非源码文本，只是渲染退化，不能作为判据。

由此得出一条必须验伪的推论：该形态本应由 HandlesExprAttr._handle_attr_call_result 的
`_FailFastAttrCallBase` 出"失败环节"详细报文（强转基座分支），而 FailFastError 全仓无
`except`（必上抛）——可现场仍是通用报文 ⇒ **那条 fail-fast 未被走到**。

本改动：`_RaiseUnresolvedExpr`（HandlesBase）在 RHS 为 Attribute 时补打
`│ 基址诊断: 基座形态=…`：
- 基座是 Name → var_struct_class 登记名 / alloca 实际 LLVM 类型 / 该名在
  Gen.structs 与 class_members 的命中情况；
- 基座是 `Call(func=BinOp(BitOr))`（强转形态）→ `_extract_union_base_class` 得到的
  联合基类名 + 其 structs/class_members 命中 + 显式标注"该走详细 fail-fast 而没走"。
新增 `BaseHandle._ExprShape`（AST 形态摘要，与 `_ExprText` 的"源码文本"分工互补，
depth≤4）。

验证：只读探针覆盖 7 种基座形态，渲染全部符合预期；GetDiagnostics 干净。未跑编译器。

2026-09-29 16:55:41 +08:00

constants

perf(hotspot): 计时串行化并改为自身耗时(exclusive)统计

2026-09-14 13:42:14 +08:00

core

fix(tpc): 属性取值为空的报文报出"基座 AST 真实形态"（附只读探针反证）

2026-09-29 16:55:41 +08:00

includes

refactor(return): 移除 @c.CReturn 多返回值处理器，只保留 -> tuple[ty1, ty2, ...]，遇到 CReturn 一律报错

2026-09-28 13:57:04 +08:00

Projectrans

feat(tpc): PROF 输出按编译启动时间分目录，不再清理旧目录