Files
TransPyC/lib/core/Handles
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
..