GVSDS/TransPyC
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
402 Commits 1 Branch 0 Tags
49930c56c7e37a0d16e2fe40367fb8ee7170d42d
Commit Graph
148 Commits
Author SHA1 Message Date
TermiNexus 49930c56c7 fix(LLVMCG/HandlesExprAttr): REnum 变体字段按唯一变体键取槽 + 修 _PointeeMatchesStruct 的「同模块前缀」误判 
【a 编译器缺陷】两处根因，同一现场（CallGenDispatch.vp:787
`len_ap: llvmlite.LLVMType* = len_val.Ty.Pointee`）：

1) `_PointeeMatchesStruct` 只比 sha1 前缀 ⇒ 把**同模块的兄弟类**当成同一个类
   （`50741ad4b4b0934d.ParamNode` 与 `50741ad4b4b0934d.LLVMType` 前缀相同，同出
   includes/llvmlite/__types.vp）。结构体分支迭代 Gen.structs 时先命中 ParamNode
   （它在 __types.vp 里声明更早）⇒ `_get_member_offset('Pointee','ParamNode')`
   直接 fast-fail，报出与真因无关的类名。判据收紧为：**同一对象** 或 **IR 全名逐字相同**
   （前缀标识的是模块，不是类）。同短名不同前缀（同一类的另一模块实例）仍由调用点的
   `_UniqShortCN`（同短名候选唯一）放行，不受影响。

2) REnum 的变体字段在旧路径上无处可取：'Pointee' 只属变体键 'LLVMType_Ptr'，
   而主类 'LLVMType' 的成员表为空（HandlesClassDef:716）⇒ 即使接收者判对类名也必 fail-fast。
   新增 `FuncGen._RenumVariantFieldOwner`，在 `_get_member_offset` 里当"主类不声明该字段"时改按
   变体键取偏移。判据（逐条可查）：① 主类经 `_IsRenumLayoutClass`（唯一判据源）判为 REnum；
   ② 变体键固定 `<主类短名>_<变体名>` 且成员表**首项恒为 `__tag`**（唯一产源：
   HandlesClassDef._EmitREnumLlvm 与 HandlesImports 的 REnum 跨模块注册）；
   ③ 恰有**一个**变体声明该字段（多个 ⇒ 不猜，照常 fail-fast）；④ 变体 struct 已注册。
   槽位正确的依据：变体 struct 的 body 是**主 REnum 镜像** `{i32 __tag, <max_variant_payload>}`，
   变体成员表 `[__tag] + 载荷` 与主 REnum 槽位一一对应。

3) 载荷槽按**最大变体**宽度物化（'Pointee' 槽是 i64），而字段本身声明为指针 ⇒
   新增 `HandlesExprAttr._RenumVariantPayloadType` / `_CoerceVariantPayload`，在
   `_gep_and_Load_member` 载入后按字段声明类型收口（int→ptr: inttoptr；ptr→ptr: bitcast；
   int→int: trunc/zext；不可转换原样返回，交下游照常 fail-fast）。非 REnum 变体键逐字不变。

冒烟（临时脚本已删）：_PointeeMatchesStruct 5 例、_RenumVariantFieldOwner 7 例、
载荷类型与转换 6 例、_get_member_offset 钩子（绑定真实方法）5 例 —— 全部通过。
 2026-09-30 12:46:37 +08:00
TermiNexus 64ddabbe17 feat(HandlesAnnAssign/HandlesExprAttr): 左值注解靶型提示（target-typing）——属性链读错类名时按注解类兜回 
现场：CallGenDispatch.vp:787 `len_ap: llvmlite.LLVMType* = len_val.Ty.Pointee`
报 "[fast-fail] 属性 'Pointee' 在类 'ParamNode' 中找不到（class_members=2 个: ['Next','Ty']）"。
'Pointee' 的真实归属是 LLVMType 的 REnum 变体镜像字段（LLVMType.Ptr.Pointee，
includes/llvmlite/__types.vp:33-34）；ParamNode 只有 Next/Ty。更隐蔽的是**两边都有 Ty**
（Value.Ty = rawptr[LLVMType]、ParamNode.Ty = 裸 rawptr = i8*）⇒ 读错类不会当场报错，
只静默把类型变成 i8*，再往下 `.Pointee` 才炸。

机制（与 TPV translate_value 的 target_ty「使用处真实站点种类」同思路）：
  ① HandlesAnnAssign._EvalRhsWithTargetHint：注解赋值求值 RHS 前，把**注解指向的结构体类**
     作为 `Gen._TargetStructHint` 传给属性链解析；求值结束（含异常）复位，不跨语句泄漏。
     两个 RHS 求值点（_reg_values 提升路径 + 常规路径）都改走该入口。
  ② HandlesExprAttr._apply_target_struct_hint：**仅当两条件同时成立**才改判——
     Ⅰ 当前解析出的类（或解析不出）**不声明**该字段（此刻原本会 fail-fast）；
     Ⅱ 靶型类**确实声明**该字段。
     任一不满足即原样返回（不猜、不篡改本来正确的链）；改判时 `_vlog().warning` 留痕。
     接入点：char*（i8*）分支与单级 Name 分支（含"原键解析不出"的情形）。

验证：py_compile 通过；`_apply_target_struct_hint` 冒烟 7 例全部符合预期——
无提示原样 / 原类不声明且靶型声明⇒改判（本次现场）/ 原类声明该字段⇒不改判 /
原键即靶型⇒原样 / 原键解析不出且靶型声明⇒改判 / 靶型也不声明⇒原样 / 靶型类不存在⇒原样。
 2026-09-30 12:28:39 +08:00
TermiNexus 43853bc455 fix(HandlesExprAttr): 基座 pointee 与 Gen.structs 的匹配补「同 sha1 前缀」与「同短名唯一候选」 
现场（Repl.vp:802）：`ct_names: list[str]* = GenApi._g_gen.TypeGenCType.CTypedefNames`
的基座 `.TypeGenCType` 取值后 pointee 为 `%"750b8c10137d273e.TypeGenCType"*`（= 撤销
6a287b9 后的新 sha1），而 Gen.structs（250 键）里没有该 IR 名的实例 ⇒ 旧判据只有
"身份相同 / IR 全名逐字相同" ⇒ 全部未命中 ⇒ 属性链求值为空 → 带注解赋值判定"无值可存"
而终止编译。（a18ca4da 的记账正是把"基座形态 / pointee / 键数"三项事实直接印了出来，
本轮不必再猜。）

改动（判据分级，强到弱；找不到仍留痕失败，不兜底造类型）：
  ① 身份相同（原判据）；
  ② IR 全名逐字相同（原判据，覆盖"同名第二份实例"）；
  ③ 同 sha1 前缀 —— IR 名形如 `<sha1>.<短名>`，前缀相等即"同一模块的同一类"；
  ④ 同短名——**仅当候选唯一**时放行（调用点算 `_UniqShortCN`）：两个及以上同名类无法
     判定是哪一个，宁可留痕失败也不选错布局（同名类冲突在本仓一律以 sha1 全名区分）。
同时把"未命中"记账扩为：列出分级判据、同短名候选清单，以及"候选 >1 会被主动拒绝"。

验证：py_compile 通过；`_PointeeMatchesStruct` 冒烟 6 例（身份 / 同名第二份实例 /
同短名不同 sha1 / 裸短名 / 不同类 / 非 Identified 一侧）全部符合预期。
 2026-09-30 12:20:20 +08:00
TermiNexus 2aa55f36b9 fix(LLVMCG/Handles): GEP 基址 opaque 时按同短名找已具化孪生体并 bitcast；守卫报文补实例清单 
现场：includes/ast/astaux.vp:165 `self.arg = _copy_str(pool, arg)` 的基址 pointee 是
opaque 的 `%"<sha1>.Keyword"*` —— 同一类名常有两份 struct 实例（短名 'Keyword' /
sha1 全名 '<sha1>.Keyword'），"函数签名里的 self 用哪一份"与"StructGen 具化的是哪一份"
并不保证一致 ⇒ GEP 无法在编译期算元素类型（llvmlite 抛裸 TypeError），
_GuardIrBuilder 的 opaque 守卫先行 fail-fast。

改动：
1) 新增 BaseGen._FindConcreteTwin：按**同短名**（IR 全名相同者优先）在 structs 里取一份
   已具化实例（元素最多者），与既有"同名实例取字段最多版本"（HandlesAssign:1156-1163）
   同一判据；返回 None 表示确无孪生体（真因 = "body 从未 set_body"）。
2) 写入路径 HandlesAssign（`self.字段 = ...`）：pointee opaque 时 bitcast 到孪生体，
   并把它同时用作 struct_type 与 `_get_member_offset` 的 hint ⇒ 偏移与 GEP 同源。
3) 读取路径 HandlesExprAttr._gep_and_Load_member 共用同一工具函数（读写两路同判据，
   避免"写修了读没修"再吃一轮）。
4) opaque-GEP 守卫报文补"同短名 struct 实例（key(IR 名)=槽数）"清单：清单含已具化项
   ⇒ 属"偏移与 GEP 未同源"；全是 opaque ⇒ 属"body 从未 set_body"——一次报文即可判定是哪一侧。

找不到孪生体时**不兜底**：仍由守卫 fail-fast 并报出实例清单（本仓"不许静默兜底"约定）。

验证：py_compile 通过（BaseGen / HandlesAssign / HandlesExprAttr 三文件）。
 2026-09-30 11:57:07 +08:00
TermiNexus 55cbf1d261 fix(HandlesImports): 继承前缀前置改为"按表头判幂等"，不再按名字过滤整块（重名继承项不再被删） 
类别：a 编译器缺陷（静默删掉布局条目，使继承段下标整体前移、写到类型不同的槽）。

问题（旧判据）：`_EmitExternalClassDeclLlvm` 的前置段用
`nm2 not in {class_members[ClassName] 整表所有名字}` 过滤祖先块。该判据把
**与子类自有字段重名的继承项整条删掉**，于是继承段与 body 的继承前缀失去一一对应：
被删项**之后**的继承字段表内下标整体前移 k（k = 被删项数），而查询侧回退路径用
`base + 表内下标`（FuncGen._get_member_offset）⇒ 落到类型完全不同的槽。
现场（本轮）：TypeGenCType 重复声明 5 个父类已有字段后，继承字段
LastBuiltinsTypedefResult 的下标 32→27，`= "t.CPtr"` 写进 i32 槽 ⇒
"指针隐式转整数已禁止：不能把指针类型 i8* 赋给整数类型 i32"。

新判据（抽成模块级 PrependInheritedBlock，可独立验证）：
  ① 不删块内条目——块内每项都对应 body 的一个继承槽，删任一项都会整体前移；
  ② 幂等——只问"表头前 len(块) 项的名字序列是否等于祖先块的名字序列"，相等即整块
     已前置 → 不再前置（保住 2026-08-10 修的重复字段问题：BasicBlock [Next, Next, …]）；
  ③ 同名并存——子类自有字段与继承项同名时两者都留（定义端 body 同样是"继承前缀 +
     自有段"，两侧槽数一致）；源码层面的这种重名已由 HandlesClassDef 的"字段名遮蔽
     fail-fast"拦下（1903ed14）。

冒烟（纯逻辑，跑完删除）：首次前置=块+自有；重复调用不再前置；**同名项仍全保留**
（对照旧实现会删掉块首项 ⇒ 下标前移）；空块 no-op。py_compile 通过。

已知残留（写进函数文档）：若此前只前置过部分祖先块（父类表当时较短），本次会整块再前置
一次 ⇒ 该前缀出现重复条目；调用点上方刚对父类 force 重载（块内容稳定），该情形仅在
"父类表被中途改写"时出现，且重复条目会在成员槽失败报文的"名序"里直接可见。
 2026-09-30 11:18:07 +08:00
TermiNexus a43513c9a7 fix(FuncGen): 成员表与 body 等长时不再做类型对齐校准（base 恒为 0），修 TypeGenMixin 字段偏移平移 
判据：_member_base 的 delta 长度启发式在 _Delta == 0 时给出 base=0（FuncGen.py:441），
而 base=2 **只可能**来自其后的"类型一致性校准"（:446-480，对 b∈{0,1,2} 逐项比类型取高分）。
但该校准用的是**严格类型相等**：声明侧的联合类型（如 `list[str] | t.CPtr`）可能被记成
折叠后的 i8*，而 body 槽仍是具体指针（`%list[str]*`）⇒ b=0 丢掉这些匹配，某个平移 b
却能靠指针槽互相撞分拿到更高分。
_Delta == 0（成员表项数 == body 槽数）本身就是"逐位对齐"（定义端 body 由成员表生成；
跨模块端 body(.stub.ll) 与 .vpi 同一声明顺序）⇒ base 必须为 0，此时不应再校准。

现场（本次）：TypeGenMixin 41 成员 / 41 槽（@t.NoVTable，_Delta=0），base 被抬到 2 ⇒
Generator.vp:136 `SubTypeGen.Gen = self`（Gen 声明 `%"47382dc8277c9d28.Generator"*`、
正确槽为 0）写到槽 40（`%"6fbe68e8fca81223.TypeSpecArena"*`）⇒
"指针隐式转换已禁止（非基本类型（结构体/类/联合））：不能把指针类型 … 隐式转为 …"。
（该报文本身是上一提交 909d8ff0 补的"成员槽来源明细"，这次正是靠它直接读出了
base/下标/声明槽类型/布局槽类型四项事实。）

附带：成员槽失败报文再补"名序"（_DescribeMemberSlot 打印 index:name 全表）——偏移算错时
第一现场就是"名序与 body 布局不同源"，逐项列出即可直接判定是哪一侧漂移，不必再猜。

验证：py_compile 通过。_Delta != 0 的既有校准现场（ast.Constant 的 `cnst.lineno` 落到
pool 槽等）不受影响（本次只加前置条件，未改校准逻辑本身）。
 2026-09-30 11:15:58 +08:00
TermiNexus de89fda73d fix(HandlesClassDef/DeclarationGenerator): 未声明字段不再静默兜底 i32，推不出类型即 fail-fast 
类别：a 编译器缺陷（静默兜底推断）+ 隐患预防。

判据（为什么必须去掉 i32 兜底）：成员类型是 struct 布局的唯一来源，静默把"没声明/
推不出"的字段当成 i32 会把错误推到下游——值域不匹配时表现为与真因无关的报文
（同族既有现场：`free_lists: uint64*` 被当成 i32 后，`self.free_lists = base`(i8*) 报
"指针隐式转整数已禁止"）。项目约定：类型信息缺失立即终止（与同函数 `self.X: T` 分支
HandlesClassDef.py:1356-1386 已有 fail-fast 同口径）。

改动 1（定义端布局，权威侧）HandlesClassDef._scan_node_for_self_assign 的 Assign 分支：
  删除 `MemberType = ir.IntType(32)` 默认值，改为显式 `MemberType = None` + 白名单定型；
  推不出即 compile_error（含 文件:行:列、源码行、取值原文、建议写法，行号按 _line_offset
  还原）+ sys.exit(1)。
  采纳形态（逐条写进注释，必须与 stub 侧一致）：
    整型/布尔字面量→i32；浮点字面量→double；字符串字面量→i8*；
    值为本方法带注解形参→该形参类型；白名单调用 float()/double()→double、char()→i8、
    int()/long()/short()→i32、`x.len()`→i32；其余（None 字面量/BinOp/任意调用…）→终止。

改动 2（stub 声明侧）DeclarationGenerator._CollectOwnMemberTypes 的 Assign 分支：
  删除 `InferredType = 'i32'` 默认值，改白名单 + 推不出即 raise `[FATAL] …拒绝静默写成
  i32`；同时纠正两处与定义端不一致的映射：浮点字面量 'float'(f32) → 'double'(f64)，
  布尔字面量 'i8' → 'i32'（定义端 bool 走 int 分支），否则 stub 与定义端槽宽/类型分叉。

预检（确认不打断既有构建）：用 TPC 自家解析器扫全工作区 .vp（678 类；口径 =
类体 AnnAssign + 任意位置 `self.X: T` + 祖先传递声明），"未声明字段 + 首次裸赋值"
实例数 = 0（曾疑似的 4 例 `self.Next = None` 均为继承字段：G4Node/Value 继承
GSListNode 已声明 Next）。

冒烟（合成样例，跑完删除）：
  A `self.flag = None`（未声明、None 无类型信息）⇒ SystemExit(1) + 明确报文；
  B `self.n = 5`（可定型）⇒ 正常翻译；C `flag: int` 已声明后赋 None ⇒ 正常翻译。

已知残留（本次未动，已在代码注释里写明，避免下次盲修）：stub 侧方法体内裸
`self.X = ...` 仍被 seen_member_names 过滤（该集合只含本类自有声明、不含继承字段）；
若放行，继承字段（如 G4Node.Next）会被当成自有字段重复加槽 → 反而制造布局分叉。
要放行必须先在该处补"祖先字段名"判定。
 2026-09-30 10:58:23 +08:00
TermiNexus 1903ed14f6 fix(HandlesClassDef): 类体字段与祖先字段重名 ⇒ fail-fast（消"继承段错位写错槽"与 split-brain） 
类别：a 编译器缺陷（静默写错槽）+ c 源码违规（子类重复声明父类字段）的入口拦截。

判据（为什么重名必须终止，而不是容忍）：
1. 子类同名声明会成为**自有字段**，与**同名继承项**在 class_members 里并存；跨模块侧
   的前置过滤器（HandlesImports._FlattenExt 前置段 :2516-2521）按"名字已在表内"过滤
   ——它本意只是防同一函数重入时重复前置，却把**同名继承项整条丢掉** ⇒ 继承段与
   struct body 的继承前缀失去一一对应：被丢项**之后**的继承字段表内下标整体前移 k，
   而查询侧回退路径用 `base + 表内下标`（FuncGen._get_member_offset）⇒ 落到类型完全
   不同的槽。现场：TypeGenCType 重复声明 5 个父类已有字段后，继承字段
   LastBuiltinsTypedefResult（下标 32）前移为 27 = CTypedefNameIdxBuilt(i32)
   ⇒ `self.Gen.TypeGenCType.LastBuiltinsTypedefResult = "t.CPtr"` 报
   "指针隐式转整数已禁止：不能把指针类型 i8* 赋给整数类型 i32"。
2. 父类方法按父类布局访问该名字的槽、子类方法按自有槽访问 ⇒ 同一变量 split-brain
   （一侧写、另一侧读），运行期静默错值。

实现：在类体自有字段收集段之后（:1047-1116）比对"自有字段名"与"沿 class_parents
传递收集到的全部祖先声明字段名"，命中即 compile_error（含 文件:行:列、源码行、
祖先类名与逐字段明细，行号按 _line_offset 还原）+ sys.exit(1)。自有段用快照切分
（:903），祖先未就绪时视为无祖先 ⇒ 只少报不误报。

预检（避免新检查打断既有构建）：用 TPC 自家解析器扫 App+includes 全部 .vp
（226 文件 / 382 类，口径=类体 AnnAssign + __init__ 带注解 self.x），既有代码
重名遮蔽数 = 0。

冒烟（合成样例，跑完删除）：
  正例 class Child(Base) 重复声明 A ⇒ SystemExit code=1，报文给出 Child/A/Base/6:4；
  反例 Child 只声明新字段 C ⇒ 正常翻译。

配套：TransPyV 侧已撤销 TypeGenCType 的重复声明（0e5ebd0）。
 2026-09-30 10:50:23 +08:00
TermiNexus 909d8ff0eb fix(诊断): _get_node_info 还原自动注入 import 的行偏移；属性写入失败补成员槽来源明细 
1) 行号还原（b 机制缺陷，实测可证）：Phase2Translator._inject_auto_imports 在源码头
   注入 import _list/_dict/json，AST 节点行号整体下移 N
   （translator._line_offset = N），而 Gen._current_source_lines 是**磁盘**原文。
   BaseGen._get_node_info / _DescribeValueNode 此前直接用 AST 行号读源码 ⇒ 同一次
   fail-fast 里出现两套互相矛盾的行号：_ErrorStack 帧印磁盘行 1140/1141，
   _get_node_info 印 1142，并把源码显示成 1142 行的 `return "t.CPtr"`
   （真实错误行是 1141 的 `...LastBuiltinsTypedefResult = "t.CPtr"`，与被指语句无关）。
   新增 BaseGen._DiskLineno，判据与 HandlesBase._FailFastFixedArrayKeyword:687、
   HandlesAssign._RaiseGlobalAttrError:2051、LlvmGenerator/HandlesBody 的
   _ErrorStack 各站点逐字一致；标签行号（_current_node_info）与源码行一并还原。

2) 成员槽来源明细：HandlesAssign 的「对象.字段 = 值」写入路径（:1182）此前
   _StoreWithCoerce 失败时只报隐式转换禁令，不报目标槽来源，报文与被指语句、
   偏移对不上。现与 `self.x = ...` 路径（:897-905）同口径补 _DescribeMemberSlot：
   附上 class_members 声明侧（项数/base/表内下标/声明槽类型）与布局侧
   （struct name/元素数/elements[offset]）两侧数据，可直接判定是声明侧退化
   还是布局侧退化（本次现场即"表内下标被同名继承项过滤移位"一类）。
 2026-09-30 10:46:42 +08:00
TermiNexus a18ca4da3b fix(ExprAttr): 嵌套属性读的每个 silent return 都留痕（含内层失败原因链），Repl.vp:802 类错误不再只能看到"基座形态" 
类别：a 编译器缺陷（可观测性补齐：报错点与真因相隔数层）

现象：TPC 编译 TransPyV/App/lib/core/Repl.vp:802
  `ct_names: list[str]* = GenApi._g_gen.TypeGenCType.CTypedefNames`
报「带注解赋值表达式 …（Attribute 形态）编译期求值为空（表达式未解析出目标、无值可存）…
赋值将被跳过」，报文里只有「基座形态=Attribute(.TypeGenCType←Attribute(._g_gen←Name(GenApi)))」，
看不出是三级链的哪一级失败、为什么失败。

判据：`_handle_attr_nested`（多级属性读）里有 7 处 `return None` 是**静默**的，而
`Gen._LastAttrNone`（`_NoteAttrNone` 记账，供 `_DescribeAttrBase` 回显"读取侧原因"）只在
`_handle_attr_name`/`_gep_and_Load_member` 一侧登记 ⇒ 本函数的失败在报文里完全没有原因。
且嵌套读取时**内层**的记账会被外层覆盖，即使内层登记了也回显不出来。

修法（纯记账，不改任何判定/IR）：
1. `_handle_attr_nested` 的每处静默 return 都调 `_NoteAttrNone` 记下**具体事实**：
   · 基座求值为空/非指针 → 附 type + **内层链的失败原因**（把 `_LastAttrNone` 里"字段名不同"
     的那条记录串进来，形成原因链）；
   · 类名提示未命中 Gen.structs 键（报 structs 键数）；
   · struct 实例类型异常；
   · body 仍 opaque 且无泛型特化成员；
   · **字段在类中取不到偏移**（报成员表项数 / body 槽数 —— 跨模块成员表缺失或漂移的关键判据）；
   · 槽是 void 占位；
   · 结构体分支 pointee 未匹配任何类（报 structs 键数）。
2. `_DescribeAttrBase` 的回显键是 (字段名, 类名)，本次登记与报错节点一致 ⇒ 下次同类报错将
   直接给出"读取侧原因=…"，一轮定位到级与因。

验证：py_compile EXIT=0。真因证据（同一现场、另一侧）：`TypeGenCType` 类体一个字段都没声明，
5 个字段全靠方法体裸 `self.x = ...`；其 .vpi（temp/05d515186a7c3668.vpi）里确实没有
CTypedefNames —— 跨模块成员表缺该字段即本次链断之处，已在 TransPyV 侧按"跨模块可见字段
必须在类体声明"补上（见另一仓 commit）。
 2026-09-30 09:59:27 +08:00
TermiNexus c86ecb0c89 refactor(LLVMCG/Handles): 直建 ir.Function 点全部收敛到幂等入口，3 处不再吞 fail-fast 
类别：a 编译器缺陷（同一根因的其它变体收口：函数声明创建的唯一入口 + fail-fast 不被吞）

背景（前几轮已修两处）：llvmlite 的 `Function.__init__` 不是事务性的（名字在 `_set_name`
就进 module.scope，之后建 Argument/ReturnValue 才断言类型，最后才 add_global），中途失败会
留下悬空名字；本仓已加两道防线：全局守卫 `InstallFuncCreateGuard()`（回滚名字 + 带调用点的
FailFastError）与唯一幂等入口 `_CreateOrReuseFuncDecl`（创建前自检、同名同类型复用、异类型
带两侧签名 fail-fast）。但仍有 20+ 处**绕过入口直建**（同名时抛裸 DuplicatedNameError、且
名字被占/半注册时只能看到没有上下文的名字），以及若干处 `except Exception` 会把这颗
FailFastError 吞掉（声明静默缺失、真因丢失）。

改动：
1. 创建点收敛（21 处，行为等价或更严）——`X = ir.Function(<gen>.module, <fty>, name=<N>)`
   → `X = <gen>._CreateOrReuseFuncDecl(<N>, <fty>)`：
   · Handles：HandlesAnnAssign[llvm.memcpy]、HandlesAssign[llvm.memcpy.p0i8.p0i8.i64 ×2]、
     HandlesBase[GetOrCreateFuncDecl / GetOrCreateStubFuncDecl]、
     HandlesExpr[malloc]、HandlesExprBuiltin[strlen / llvm.memcpy]、
     HandlesExprCall[llvm.* 与普通 / win32 API / strlen / llvm.memcpy]、
     HandlesAsyncFunctions[malloc / create_* / resume_* / CRT 声明 / free]、
     HandlesExprLambda[lambda 包装]、HandlesFunctions[_replace_function_decl 的 old_func=None 分支]、
     HandlesImports[output stub 按需加载]
   · LLVMCG：BaseGen[_DeclareExternalFunc 与 6 处 --hotspot-sites 内部符号]、
     ExprGen[llvm.pow.f64]、VaArg[llvm.va_start / llvm.va_end]
   原有 globals/functions 预检查与随后的 `Gen.functions[...] = X` 赋值一律保留。
   注：`_DeclareExternalFunc` 收敛后外部声明会同时登记进 `self.functions`（幂等入口固有行为，
   与既有 `get_or_declare_c_func` 一致；该路径仅 --hotspot-sites 调试特性使用）。
2. fail-fast 不再被吞（3 处）：在包裹创建的 `except Exception` 首部加
   `isinstance(_e, FailFastError) → raise`：
   · HandlesExpr[malloc 的 null 回退分支]、HandlesExprBuiltin[strlen]、HandlesExprCall[strlen]
   （其余异常维持原行为，本轮不扩大 fatal 面。）
   另有 HandlesFunctions / HandlesImports 的同类 handler 前几轮已具备 FFE 重抛，本次未重复改。

验证：13 个改动文件 `py_compile` 全部 EXIT=0；冒烟 4 例通过——同名同类型复用同一对象、
异签名 → FailFastError（报文含两侧签名 i64/i32）、名字被非函数全局占用 → FailFastError、
`llvm.va_start` 幂等。另：`ir.Function(` 在 lib 内仅剩 `BaseGen._CreateOrReuseFuncDecl` 内部
这一处（豁免点）；`DecoratorPass.py` 的 `module` 为外部传入（非 Gen 的模块）故其两处保持原样。
 2026-09-30 09:53:41 +08:00
TermiNexus 8f1ec5b715 fix(LLVMCG): llvmlite Function 创建事务化 + 不再吞 fail-fast，悬空名字不再复现 
类别：a 编译器缺陷（TPC 侧）

现象：编译 StubMergerIR.vp 时 `_EmitExternalFuncDeclLlvm` 报「函数声明名字悬空占用：
'50741ad4b4b0934d.LLVMTypeCore.__init__' 已进 module.scope，但 module.globals 中无对应
对象」，且该 FailFastError 被 `_LoadModuleDeclarationsFromFile` 的节点级 `except Exception`
吞成一行 WARN「忽略节点 ClassDef LLVMTypeCore 异常」后 continue。

机制（判据已写进代码注释与报文字段）：
1) llvmlite 的 `Function.__init__` 不是事务性的：名字在 `_set_name` 即进 module.scope，
   之后逐个建 Argument/ReturnValue 才做类型断言，最后才 add_global；中间任一步抛错都不
   回滚 scope ⇒ 留下「globals 查无、scope 已占用」的悬空名字，后续同名创建只能报裸
   DuplicatedNameError（或本仓的「名字悬空占用」），而真因——上一处被吞的创建失败——已丢失。
   修法：BaseGen 新增 `InstallFuncCreateGuard()`（随模块导入装一次），在**失败路径**上
   回滚名字（补 llvmlite 缺的那半截事务，模块状态可重试）并抛 FailFastError，报文含
   函数名 / 本次签名 / 原始异常 / 创建调用点（栈上首个非 llvmlite、非包装函数的帧）；
   `DuplicatedNameError` 原样上抛——那是各调用点有意处理的正常分支（如「已存在则复用」）。
2) 首建失败与该 FailFastError 被 5 处兜底吞掉，使真因退化成一行 WARN：
   · HandlesImports._LoadModuleDeclarationsFromFile 节点级 except（本现场的直接来源）
   · HandlesImports stub 声明加载循环的两层 except
   · HandlesImports._TryLoadFuncDeclsFromOutputStub 的裸 `except Exception: pass`
   · HandlesFunctions._replace_function_decl 的 `except Exception: return old_func`
     （此处 old_func 必为 None ⇒ 调用点把 None 当函数声明用）
   修法：一律 `except FailFastError: raise`；其余异常维持原有口径（严格模式上抛 / 其余告警）。

验证：4 例冒烟（非法签名 → FailFastError 且报文含调用点；名字已回滚 ⇒ 同名可重试成功；
重复创建仍是 DuplicatedNameError 且旧名未被回滚；合法创建零副作用）全部通过；
BaseGen / HandlesImports / HandlesFunctions 三文件 py_compile 通过。
 2026-09-29 23:31:57 +08:00
TermiNexus 90d81df4f8 fix(tpc): 自指针指向 opaque 同名实例时归一为具化实例；GEP 边界拦下 opaque pointee 
类别 a（编译器缺陷）：llvmlite 的 typed pointer GEP 必须在编译期算出元素类型——
`GEPInstr` → `ptr.type.gep(i)` → `IdentifiedStructType.gep` → `self.elements[i]`，
对 **opaque**（elements is None）pointee 抛裸 TypeError（'NoneType' object is not
subscriptable）。现场：includes/ast/astaux.vp `Keyword.__init__` 的
`self.arg = _copy_str(pool, arg)`，经 HandlesAssign._HandleAttributeStoreLlvm:869
的 GEP 崩溃。成因：同名 struct 存在**两份实例**——函数签名/变量里那份仍 opaque，
类键 `Gen.structs[ClassName]` 上那份已具化；偏移取自类键那份、GEP 却用 self 那份。

- HandlesAssign._HandleAttributeStoreLlvm：GEP 前把 self 指针 bitcast 到**有 body 的
  那份实例**（仅当 self 的 pointee opaque 且类键实例已具化），并把该实例作为
  StructHint 传给 _get_member_offset —— 偏移与 GEP 必须同源（与属性读取路径
  _gep_and_Load_member 的 415916b3 同口径）；max_offset 的取值也补上 elements 为
  None 的判据（原实现会对 opaque 实例 len() 触发断言）。
- BaseGen.RequirePointerOperand 新增 RequireConcretePointee（GEP 专用）：基址指向
  opaque 具名结构体时 fail-fast，报文给出基址类型、结构体名、GEP 名与当前节点位置，
  不再落到 llvmlite 的裸 TypeError（typed pointer 下"GEP 指向 opaque 结构体"无任何
  合法场景：元素类型必须编译期可知）。

本地冒烟：opaque pointee 被拦下（FailFastError，而非 llvmlite 的 TypeError）；
具化 pointee 正常通过。
 2026-09-29 22:10:11 +08:00
TermiNexus 4734a54aed fix(tpc): 函数声明创建前自检签名与半注册名字，DuplicatedNameError 不再裸抛 
类别 a（编译器缺陷）：llvmlite 的 Function.__init__ 顺序是
  NamedValue.__init__ → _set_name → module.scope.register(name)      【名字占用】
  → 逐形参 Argument(...) / ReturnValue(...)（内部 assert isinstance(typ, types.Type)）
  → module.add_global(self)                                        【进入 globals】
中间任一步抛错，Python 都不会回滚 scope ⇒ 留下"半注册"名字：module.globals 查无、
module.scope 已占用。而 _EmitFunctionForwardDeclLlvm 的 `except Exception` 在非严格
模式**静默 pass**（严格模式也只 LogWarning）⇒ 真因（返回类型或形参不是 llvmlite
Type，典型 None＝注解未解析出来）被吞掉，直到定义阶段 _EmitFunctionLlvm →
_CreateOrReuseFuncDecl 才以 DuplicatedNameError 暴露，报文只有名字、没有两侧信息
（现场：972cf2b7756765d5.ImportsGenMixin._index_imported_module，本次构建 723s 后失败）。

- BaseGen._CreateOrReuseFuncDecl（唯一幂等入口）新增两条**创建前**自检：
  ① 签名自检：return_type 与 args 逐项必须是 ir.Type，否则在名字注册之前就报出
     "哪个位置 / 什么类型 / 完整签名 / 当前节点位置"；
  ② 悬空名字自检：name 已进 module.scope 而 module.globals 无对象 ⇒ 直接报出
     "此前同名创建中途失败且异常被吞"，不再落到裸 DuplicatedNameError。
- HandlesFunctions._EmitFunctionForwardDeclLlvm：该 except 不再吞非 FailFastError
  异常（原：非严格静默 pass / 严格仅 warning）⇒ 改抛 FailFastError，附函数名、
  本次签名、原始异常类型与消息、当前节点位置。

本地冒烟（5 例全过）：合法签名建成功；None 返回类型拦下且不留半注册名字；None 形参
拦下；悬空名字报状态事实；同签名二次调用仍幂等复用。
 2026-09-29 20:45:26 +08:00
TermiNexus 415916b3dd fix(tpc): 成员偏移以「实际 GEP 用的 struct 实例」为准，并报出双实例不一致 
类别：a（编译器缺陷 —— 偏移与 GEP 不同源，整类字段偏移平移）

现场：TransPyV/App/lib/core/Gen/Class/ClassGenGeneric.vp:346
    return ast.Constant(pool, cnst.const_kind, cnst.int_val, cnst.float_val,
                        cnst.str_val, cnst.lineno, cnst.col_offset)
报「调用参数类型不匹配：指针类型 %"c772afbbfd495aca.MemManager"* 不能隐式转换为
整数参数 i32」，逐项列表显示实参 [6]（= cnst.lineno）求值成 MemManager*。

取证（TransPyV/temp/5df907d3a02a0bac.stub.ll:21/:23）：
  %"…Constant" = { [0]i8*(vtable) [1]AST*(parent) [2]MemManager*(pool)
                   [3]i32(lineno) [4]i32(col_offset) … }
  __new__(Constant*, MemManager*, i32, i64, double, i8*, i32, i32)
成员表扁平序为 [parent, pool, lineno, col_offset, …] ⇒ base=1 时 lineno 偏移 3
（正确），base=0 时偏移 2 = pool，正是报出的那个指针类型；而 col_offset 偏移
3 落到 lineno 仍是 i32，所以**只有 [6] 报错** —— 与现象逐位吻合。

根因：FuncGen._member_base 的布局取自**类键** self.structs[cls]，而 GEP 用的是
**取值处** ObjVal.type.pointee 那一份实例。同名类双注册（或一份已从 stub 加载完整、
另一份仍 opaque）时两份布局不同 ⇒ 用一份算偏移、用另一份读，整类字段偏移平移。
_class_has_vtable 对跨模块 AST 类恒为 False（其 docstring 已记录该已知静默路径），
base 只能靠 delta + 类型校准救回，两实例不同源时即失守。

改动：
1. FuncGen._member_base(ClassName, StructHint=None)：hint 为**同类**（短名相同）的
   struct 实例时，以它计算 delta / 首元素 vtable 判据 / 类型校准；当它与类键上的
   实例不是同一对象时，每类一次 vlog().warning 报出两侧名字与元素数（opaque 或
   元素数），使"双注册"这一事实不再静默。
2. FuncGen._get_member_offset(..., StructHint=None) → _BaseNow() 透传（base 仍现算，
   不缓存）。
3. HandlesExprAttr._handle_attr_name：把 ObjVal.type.pointee 作为 hint 传入。

不传 hint 时行为与改前逐字一致；其余偏移消费点（字段写入 / 构造初始化等）本轮未动。
 2026-09-29 18:18:49 +08:00
TermiNexus 935a5b372b fix(tpc): 属性读取返回 None 时登记「确切原因」，5 个 return None 点不再同义 
类别：a（编译器缺陷 —— fail-fast 报文缺根因区分，5 个不同故障同报"求值为空"）

现象：`self.Gen.ExprGen.translate_value(builder, pool, mod, ie.orelse, ...)`
（ExprGenOps.vp:97）报「调用实参编译期求值为空」，而同函数同对象的 `ie.test`
（:43）、`ie.body`（:78）求值正常。三个字段在 `IfExp` 布局里是**连续三槽**
（stub: %"…IfExp" = { i8*, AST*, MemBuddy*, i32×4, list*, AST*(test),
AST*(body), AST*(orelse) }，共 11 元素），只有最后那个失败 ⇒ 必然是"偏移越出
body 元素数"这一类，但报文只说"求值为空"，无法与"类名未解析 / 基座求值为空 /
结构体未匹配 / stub 无 body"区分。

改动（纯取证，不改变任何判定与 IR）：
1. HandlesBase 新增 `_NoteAttrNone(Gen, ClassName, AttrName, Reason)`：把
   `(类名, 字段名, 原因)` 记到 `Gen._LastAttrNone`。
2. HandlesExprAttr 的 5 个 return None 点全部登记：
   - `_gep_and_Load_member`：偏移为 None；**偏移越界**（附 offset / body 元素数 /
     st 版元素数 / 成员表项数）。
   - `_handle_attr_name`：类名未解析；基座自身求值为空；结构体未匹配（附 ObjVal
     类型）；stub 无 body；槽位越界（附 offset / pointee 元素数 / st 元素数）。
3. `_DescribeAttrBase` 追加三项事实：`struct body 元素数`、`字段 X 计算偏移`
   （`_get_member_offset`，异常则报异常类型）、以及与被报节点 (类名, 字段名)
   一致时回显 `读取侧原因=...`（不一致不回显，避免嵌套读取的旧记录冒充）。

依据：字段名在成员表里能找到却没读到值，只可能是"偏移 ≥ body 元素数"
（`_get_member_offset` 找不到字段时已 fail-fast，不会返回 None）；因此
`偏移/body元素数/成员表项数` 三个数字是判定该情况的唯一依据，必须一次报全。
 2026-09-29 17:46:58 +08:00
TermiNexus 0392ccdea0 fix(tpc): fail-fast 报文补「属性基址取证事实」，属性读返回 None 不再靠反推 
类别：a（编译器缺陷 —— fail-fast 报文缺取证事实，无法一眼定位根因）

现象：HandlesBase._RaiseUnresolvedExpr 与 HandlesExprCall._RequireArgValue 在
「属性读取值失败」时只报 Node 形态（Attribute），报错点与真因相隔数层调用，
需要人工从 Gen.var_struct_class / Gen.structs / Gen.class_members 反推。

改动：
1. HandlesBase 抽出公开方法 _DescribeAttrBase(Gen, Node) -> str（原 _RaiseUnresolvedExpr
   内联代码抽出，行为不变），对两类基座给事实：
   - Name 基座：var_struct_class / global_struct_class / alloca 类型 / 是否命中
     Gen.structs / class_members 字段数与字段名单（前 12）。
   - Call(func=BinOp(BitOr)) 强转基座：联合基类名 + 短名是否命中 Gen.structs +
     字段数，并显式标注「强转基座本应走 _FailFastAttrCallBase 详细报文，此处仍是本条
     ⇒ 那条 fail-fast 未触发」，把「另一处缺口」这一事实直接写进报文。
2. _RaiseUnresolvedExpr 改调 _DescribeAttrBase（删除内联重复代码）。
3. HandlesExprCall._RequireArgValue 在实参是 Attribute 时追加同一份基址诊断
   （与 HandlesBase 共用，保证两处口径逐字一致）。

不改变任何判定逻辑，仅补取证事实。
 2026-09-29 17:40:23 +08:00
TermiNexus b3bc94f99f fix(tpc): 「类 + t.CPtr」联合合并时传播 IsStruct，指针层数不再多算一层 
类别：a（编译器缺陷）—— 上游：联合注解 `X | t.CPtr`（X 为类）合并后多出一层指针，
类名随之在下游被当通用指针处理。

根因（一行）：
- `_MergeAllComponentTypes` 的"struct 吸收第一个 t.CPtr"规则以 `Result.IsStruct` 为
  **闸门**（该函数 :1022-1027 注释原文："仅对 struct 类型吸收第一个 CPtr（struct 变量
  默认是指针，AST | t.CPtr = AST*）"）：
      base_ptr_count = Result.PtrCount; Result.PtrCount += cptr_count
      if Result.IsStruct and base_ptr_count > 0 and cptr_count > 0: Result.PtrCount -= 1
- 但 `_MergeCTypeInfoInto` 传播 struct 时**只复制 Name、从不置 IsStruct**
  （`if Source.IsStruct and Source.Name and not Target.Name: Target.Name = Source.Name`）
  ⇒ 闸门恒假 ⇒ `list[str] | t.CPtr` 合并后 PtrCount = 1+1 = 2（应为 1）
  ⇒ 得到 `list[str]**` 而非 `list[str]*`。
- 既有同类先例（同一函数紧邻的 REnum 分支）已经写着
  `Target.IsStruct = True` 并注释"同时传播 IsStruct=True，让 CPtr 吸收逻辑生效
  （REnum 在内存布局上是 struct）" ⇒ 通用 struct 分支漏了同一个传播。

后果链（Test/FakeDuckTest/App/main.vp:111/115）：
  `parts = s1.split(',')`（`split` 返回注解 `list[str]*` ≡ `list[str] | t.CPtr`）
  声明侧解析成两层指针 ⇒ 值类型 pointee 是指针而非结构体 ⇒ HandlesAssign 的类名推断
  整块（以 pointee 是结构体为前提）跳过 ⇒ `parts` 无 `var_struct_class` ⇒
  `p0: str = parts[0]` 不走 `list[str].__getitem__`，退化成通用指针/字节索引返回整数
  ⇒ 报"整数隐式转指针已禁止"（真因在 4 行之前，报文指不到）。

修复：`_MergeCTypeInfoInto` 里 struct 标志与 Name 成对传播
（`if Source.IsStruct: Target.IsStruct = True`），恢复文档化的"吸收第一个 CPtr"语义。

（上一提交 b6526343 在调用点做了类名恢复，属同族的下游补丁；本次是上游根治，
两者不冲突：上游修好后，参数/字段/返回值等位置不再各自退化。）

验证：GetDiagnostics 干净；未跑编译器。
 2026-09-29 17:35:56 +08:00
TermiNexus b652634356 fix(tpc): 裸赋值 RHS 是"联合注解返回"的调用时，从返回注解恢复被指类名 
类别：a（编译器缺陷）—— 类型信息被静默丢成通用指针 i8*，后果在数行之后以看不出真因
的报文暴露。

现场（Test/FakeDuckTest/App/main.vp:111/115）：
  `parts = s1.split(',')` → `p0: str = parts[0]`
  报"整数隐式转指针已禁止…出错表达式: 下标表达式 Subscript"。

证据链（三段各有代码/探针依据）：
1. `_fakeduck.vp:273` 的 `def split(...) -> list[str]*`：只读探针确认 `list[str]*`
   与 `list[str] | t.CPtr` 的 AST **逐字同形**
   （`BinOp(BitOr, Subscript(Name(list)), Attribute(t.CPtr))`）⇒ 注解写法没问题。
2. 该联合形态在 LLVM 层映射成**通用指针 i8***（`list[T] | t.CPtr` 的既有约定，
   见 HandlesAnnAssign:372-383）。
3. `HandlesAssign` 原有的类名推断整块以 `Value.type.pointee` 是结构体为前提
   （:186 的 `isinstance(..., (LiteralStructType, IdentifiedStructType))`）⇒ i8* 直接
   整块跳过 ⇒ `var_struct_class['parts']` 从不登记 ⇒ `parts[0]` 不走
   `list[str].__getitem__`，退化成通用指针/字节索引 ⇒ 结果类型是整数 i8 ⇒ 赋给
   `str` 时触发 int→ptr 拦截。真因位置比报文位置早 4 行。

修复（编译器侧，不要求源码补注解）：
- `HandlesExprCall._CallReturnClass(Node, Gen)`：从被调者的 **returns 注解**取回被指
  类名。被调者候选键覆盖三种既有形态（`Name` 函数名、`<接收者类>.<方法>`、
  FakeDuck 影子类 `_str`/`_bytes`、裸 `<方法>`），取第一个能解析出类名的。
- `HandlesExprCall._ClassFromAnnotation(Ann, Gen)`：剔除 `| t.CPtr` 侧取核类型，
  泛型 Subscript 走 `_resolve_generic_slice_type` 构特化名（`list[str]`），并要求该名
  能在 `Gen.structs` / `Gen.class_members` 命中（含 sha1 前缀全名的短名归一）；
  取不到一律返回 None —— **不硬塞名字**。
- `HandlesAssign`：仅当"RHS 是调用 + 值类型是通用指针（pointee 非结构体）+
  var_struct_class 尚无该变量"这三个条件同时成立时，才据上恢复登记
  `var_struct_class` / `global_struct_class` / `_var_to_heap_ptr`。其余路径逐字不变。

验证：只读探针覆盖 7 种注解形态（`list[str]*` / `list[str] | t.CPtr` / `Foo*` /
`Foo | t.CPtr` / `ast.AST*` …），提取结果全部符合预期（未命中类名时返回 None）；
GetDiagnostics 干净。未跑编译器。

遗留（同族，下一轮）：上游"联合注解→i8*"这一步丢类名才是真根因；本次是在调用点
恢复。另外 `parts.__len__()` 在类名缺失时可能被 FakeDuck `_str.__len__` 错接，
修完建议跑一次该测试确认 `split len OK`。
 2026-09-29 17:09:42 +08:00
TermiNexus 783aba1e49 fix(tpc): 方法调用/属性调用路径的实参不再静默丢弃（收口"整体错位一格"） 
类别：a（编译器缺陷）—— 实参求值为空被静默丢弃 ⇒ 后续实参整体前移一格 ⇒ 报出与
真因无关的类型不匹配。

现场（TransPyV/App/lib/core/Gen/Func/FuncGenMixin.vp:1429）：
  `return self._lambda_scan_body(trans, ie.orelse, param_names, param_count,
                                 cap_names, cap_allocas, cap_tys, cc6)`
  → `_adjust_args` 报"指针类型 i8* 不能隐式转换为整数参数 i32"。

判据（把报文的"逐项"列表与两种假设逐位对照）：
  形参表（stub declare，与该行源码一致）：
    self, trans, node=%AST*, param_names=i8*, param_count=i32,
    cap_names=i8*, cap_allocas=i8*, cap_tys=i8*, cap_count=i32
  实测实参：i8*, i32, i8*, i8*, i8*, i32, i32（9 项）
  假设"第 3 个实参（param_names，i8*）被丢弃、末尾由 _fill_default_args 补
  cap_count 的零值 i32"⇒ 预测 arg[2..8]=orelse(i8*), param_count(i32),
  cap_names(i8*), cap_allocas(i8*), cap_tys(i8*), cc6(i32), 补零(i32)
  ⇒ **与实测逐位完全一致**。反证：若丢的是末尾的 cc6，预测序列与实测不符。
  （`_fill_default_args` 只从**末尾**按形参类型补零：HandlesExprCall.py:202-248）

修复：方法调用路径（_HandleMethodCallLlvm）与属性调用回退路径（_HandleCallLlvm）
共 7 处仍写作 `ArgVal = HandleExprLlvm(arg); if ArgVal: append(ArgVal)` —— 正是
`_RequireArgValue` 文档里点名要收口的旧写法（此前只收口了 4 处类构造）。现全部
改为 `_RequireArgValue(...)`：实参求值为空当场 fail-fast，报文含被调者、实参序号与
源表达式，**不丢弃该实参**。

同族未收口（本次不动，逐条记录）：`_ApplyKeywordArgs` 的关键字实参（:337）、
`:595` 的 UserCallArgs、`:1262`、`:1336` 共 4 处仍是旧写法。

验证：GetDiagnostics 干净；未跑编译器。
 2026-09-29 17:01:14 +08:00
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
TermiNexus 716cd61a75 fix(tpc): 属性取值失败的报文补"基址诊断" + 补掉声明加载去重签名的真实缺口 
类别：a（编译器缺陷）—— 两者都是"缺事实/漏输入"，不是放宽判定。

【一】`_RaiseUnresolvedExpr` 增打基址事实（HandlesBase）
现场：TransPyV/App/lib/core/Gen/MatchGenMixin.vp:231
  `val: ast.AST* = expr_node.value`（base 是 `expr_node: rawptr[ast.Expr]`）
  → Attribute 取值返回 None → 本报文 + sys.exit(1)。
属性读回 None 的根因只有两类：① 类名登记退化（var_struct_class 存 'rawptr' /
'rawptr[X]' / 折叠态，或压根没登记）；② 登记名与 Gen.structs / class_members 的键
不同源（短名 vs sha1 全名）。原报文只有"目标变量 + 注解 + 源码"，不含任何一项事实
⇒ 只能从"求值为空"反推。现追加一行（仅 Attribute + Name 基址时，其余形态逐字不变）：
  基址诊断: 'expr_node' 的 var_struct_class=<...>；alloca 类型=<...>；
            该名在 Gen.structs=<是/否>；class_members=<N 个字段/无该键>
与 `_DescribeMemberSlot` 同口径：列数据、不猜。

【二】`_ClassMembersReloadSignature` 的"类数"改为"逐类 (键, 表长) 元组"（HandlesImports）
上一轮 3399b44c 的签名里全局进度只记 `len(class_members)`（键数）。缺口：**某已有类的
成员表继续增长时键数不变**（典型＝父类成员后到），而父类成员正是继承前缀的唯一来源
⇒ 极端时序下会漏掉一次必要重跑。改为逐类 (键, 长度) 元组，并补记
`len(class_parents)` / `len(class_parent)`（父链登记本身也是输入）。
代价 O(类数)（约 300 项/次调用），仍远低于一次重跑的成本。

验证：GetDiagnostics 干净；py 层 import + 既有 16 例类型判定 smoke test 全过。
未跑编译器（无 includes 改动，无需重编）。
 2026-09-29 16:50:51 +08:00
TermiNexus 3399b44c2d perf(tpc): 声明加载去重 + _parse_llvm_type memo（PROF main_prof_72472 前两名热点） 
两项改动同在 HandlesImports.py，合并提交：都属"重复重跑"型浪费，且第二项是第一项
放大链的下游。

【一】声明加载按依赖签名去重（类别 a：编译器缺陷）
证据：_TryLoadClassMembersFromPyi 142,888 次 → 6,683 次落到 _EmitExternalClassDeclLlvm
（cum 103.1s）→ _generate_structs 8,059 次（cum 128.7s）→ _TryLoadStructFromStub
88,970 次 → _parse_llvm_type 909,382 次；对照模块声明发射仅 320 次 ⇒ 绝大多数是
同状态的重复发射。
根因：guard 只在"表非空 **且已登记已展平**"时短路，而"父类是泛型特化/始终不可得"
的类永远不会被 `Gen._members_flattened` 登记 ⇒ guard 永不命中 ⇒ 每次重入都重跑整套
`_EmitExternalClassDeclLlvm`（其内部又触发 _generate_structs → _TryLoadStructFromStub
→ 本方法，即每轮 4 帧的环）。
修复：新增 `_ClassMembersReloadSignature`（纯读）收录"重跑能否产生新结果"的全部输入
——全局进度（已登记类数/已展平类数）、本类成员表长度与展平登记、struct body 元素数、
各父类的成员表长度与展平登记；签名不变即直接短路，依赖一变立刻放行（不破坏"与父类/
struct 就绪顺序无关"的设计目标；与 EnsureClassMembersFlattened 的依赖签名同一思路）。
要点：键含 source_sha1（同名类分属不同模块）；**先登记再发射**（否则环上第一层重入
还会再发一次，去重被推迟一层）；发射抛异常时撤销登记（保住"失败可重试"，不让失败态
被签名冻结）；force=True 完全绕过。

【二】`_parse_llvm_type` memo + 基础类型表提升为模块常量（类别 b：漏缓存）
证据：该函数被调 1,689,809 次（cum 46.7s），`type_map` 字典每次调用现建 ⇒ 字典字面量
1.69M 次、`IntType.__new__` 9.09M 次；每个 `X*` 还要新建 `ir.PointerType` ⇒ 全程序
`_TypedPointerType.__init__` 4,596,463 次（≈12–15s）主要来自这里。
修复：拆 memo 包装 + `_parse_llvm_type_impl`（原实现逐字搬移，内部递归仍走包装）；
memo 只缓存**与 Gen 状态无关**的结果（新增 `_IsGenIndependentLlvmType`：类型图不含
`IdentifiedStructType` 且非 None——含具名结构体的结果绑定 `Gen.structs` 实例且有
泛型特化副作用，None 表示"此刻未加载"，二者都不可缓存，理由写进注释防以后被放宽）；
`_LLVM_PRIMITIVE_TYPE_MAP` 提升为模块级常量（llvmlite 中这些类型无状态、IntType
按宽度缓存同一实例，跨调用/跨 Gen 共享安全）。

验证：py 层 smoke test 覆盖 16 种类型（含 struct / struct* / [4 x struct] /
{i32,struct} / fn(struct) / fn->struct* 组合），判定全部符合预期，模块可正常 import。
未跑编译器（无 includes 改动，无需重编）。
 2026-09-29 16:31:29 +08:00
TermiNexus 467e62a45e fix(tpc): 继承前缀配槽改用 elements 快照，不再对已被重置为 None 的 body 下标 
类别：a（编译器缺陷）—— 裸 Python TypeError 崩溃 + 外层静默吞掉整条类声明。

现场：编译 includes/ast/astaux.vp 时
  HandlesImports.py:2526 `_inherited_ph.append((_nm_ph, _st.elements[_slot0_ph + _i_ph]))`
  → TypeError: 'NoneType' object is not subscriptable
（栈由 VLogger.warning 打印 exc_info 后首次可见；外层 HandlesImports.py:647
 `except Exception` 只 WARN "忽略节点 ClassDef" 就 continue ⇒ 该类声明整条
 被静默丢弃，类型解析退化。）

根因（TOCTOU）：guard 在 :2500 通过（elements is not None），但两侧之间
`_ResolveInheritedFieldNames`（:2535）会加载父类成员：
  _ResolveInheritedFieldNames → _TryLoadClassMembersFromPyi
  → _EmitExternalClassDeclLlvm → _generate_structs
而 `_generate_structs` 判定"struct body 与 class_members 不一致"时会**主动**
`existing_st.elements = None`（StructGen.py:579/:590，既有机制，为强制重新派生）
⇒ 配对时读到的 elements 已变 None。

修复：guard 通过时立即对 elements 取快照 `_elements_ph`，槽位数与槽位类型取自
**同一时刻**的布局（`_num_elements` 本就取自它，二者必须同源）；配对用快照，
不再触碰可能被重入重置的 `_st.elements`。无重入时行为与改前逐字节一致。
 2026-09-29 16:26:43 +08:00
TermiNexus 24573e5af6 fix(tpc): HandlesImports 不再静默 RecursionError + VLogger.warning 补打 exc_info 
类别：a（编译器缺陷）+ b（机制漏豁免）—— 类型解析链成环被当成"可忽略异常"吞掉，
上游根因不可见、声明静默退化。

- HandlesImports.py:978 / :1475 / :1583 三处新增 `except RecursionError: raise`，
  对齐家族口径（HandlesBase.py:1060-1068：「RecursionError 不是可忽略异常，
  是类型解析/声明发射链成环的真缺陷信号」）。成环路径：
  _TryLoadClassMembersFromPyi ↔ _EmitExternalClassDeclLlvm ↔ _TryLoadStructFromStub
  （每轮 4 帧），现场与 :2985 深探针记录一致（match.MatchOr.patterns、
  stmts.Interactive.body 等"首字段即指针/容器"的类）。
  修复前表现为一行 `WARN: HandlesImports: 忽略异常 maximum recursion depth exceeded`
  + 返回类型退化成 CInt / 形参退化成 i32。

- VLogger.py:warning() 的 exc_info 形参**从未被使用** —— 调用方传了异常却无任何
  输出，吞异常点只剩一行 WARN、栈不可见。现与 error() 同口径打印
  `Exception: <类型>: <消息>` + traceback（重复帧由 traceback 模块自动折叠为
  "[Previous line repeated N more times]"，不刷屏）。
 2026-09-29 16:16:01 +08:00
TermiNexus d3537c7b3f fix(tpc): 局部 AnnAssign 反向重建不再窄化「基类指针」声明为派生类 
【类别 a 编译器缺陷】局部带注解赋值的「反向重建」缺少方向判定，
把源码显式声明的**基类指针**落地成**派生类指针**，
再用新收紧的指针隐式转换判据翻译后续赋值时就必然失败。

现象：
  翻译 includes/ast/parser.vp 报
  「指针隐式转换已禁止（非基本类型（结构体/类/联合））：不能把指针类型
   %"….AST"* 隐式转为 %"….Name"*」，
  出错语句 `_parse_atom` 内 `node = _new_const_str(...)`（parser.vp:1921 附近）。

根因链（全部可取证）：
  1. `node` 在 _parse_atom 内首次声明于
     `node: rawptr[AST] = Name(ps.pool, name_str, ASTCtx.Load)`（parser.vp:1899），
     注解写明的被指类是 **AST（基类）**，RHS 是 **Name（派生类）指针**；
  2. HandlesAnnAssign._HandleAnnAssignLlvmInner 中「以 RHS 被指类型反向重建
     alloca」的代码块（初版快照即存在，注释自述本意是「注解退化成裸基类 / i8*，
     RHS 构造出精确特化 ⇒ 用 RHS 反向升级」）**无条件**执行：
        if isinstance(VarType, ir.PointerType) and VarType.pointee is not ST ...:
            var = Gen._allocaEntry(ir.PointerType(pointee), name=VarName)
      ⇒ node 的栈槽被落成 `Name*` 而非注解的 `AST*`；
      （既有仅有的方向判据 `_rb_is_bare_generic`，commit 0ffaadc9，只拦「RHS 是
      裸泛型基类」这一个方向，拦不住「RHS 是注解被指类的派生类」）
  3. 旧构建产物实测确认槽类型确为派生类指针：
     Test/AstTest/.tpv_build/temp/05/056a6a1271f871d2.ll 的
     `@"…._parse_atom"` 内 `%24 = alloca %"8f3ee13abe0c5527.Name"*`，
     且 `_parse_fstring` / `_new_const_str`（均返回 AST*）的返回值后面紧跟
     `bitcast …AST* → …Name*` 再 store —— 即 AST*→Name* 的**下转**此前是静默
     bitcast；2026-09-28 指针隐式转换收紧（结构体只允许上转）后，同一处变成
     fail-fast，暴露出上层这个窄化缺陷。收紧本身正确，缺陷在窄化。

修法（与既有 `_rb_is_bare_generic` 对称的「方向判定（其二）」，非兜底）：
  · 新增注解侧被指类快照 `_ann_pointee`：优先取已解析出的 `VarType.pointee`；
    注解被 TypeMerge 折叠成 i8*（rawptr[X] / t.CPtr[X]）时取同一函数上方
    635-684 已恢复进 `var_struct_class` 的 X（那正是注解写明的被指类）；
  · 仅当 `_IsInheritanceUpcastPointee(RHS 被指类, 注解被指类)` 为真
    （即注解就是合法的「基类指针」声明、RHS 只是继承上转）时**跳过重建**，
    保留注解类型，杜绝「按 RHS 窄化声明类型」。
  判据只拦这一个确定的方向错误：注解退化成 i8*/裸占位（被指类非 RHS 的基类）
  时 `_rb_is_upcast` 为假，泛型特化升级路径（commit 0ffaadc9 修的现场）不受影响。

影响面：本处是 TPC 内唯一的「以 RHS 重建 alloca」点（全仓 grep 该调用仅此一处）。
窄化取消后，槽类型回归注解声明；后续赋值/取值按正常隐式转换判定
（派生→基类为上转，放行），不再出现「先被悄悄窄化、再被判下转」的自相矛盾。

1 file changed, 31 insertions(+), 1 deletion(-)
 2026-09-29 14:53:33 +08:00
TermiNexus 4fc067e3bf perf(tpc): 按 profile 消掉两处主热点（stub 索引每 miss 重扫目录 / vtable 每类全扫函数） 
依据 PROF/main_prof_10152.prof（main_time.txt: 失败 2362.46s，72 个文件全部走
顺序 _translate_file，tottime 合计 2288.9s）:

  tottime      calls   函数
  491.7s      723782   nt._path_isdir            ← 总时长 21%
  268.6s       15762   StructGen._generate_structs
  182.9s      479819   nt.listdir                ← 8%
  87.2s    657640754   builtins.isinstance
  78.6s     41514263   ntpath.join
  75.9s     83047878   ntpath.splitroot
  75.7s         1631   StructGen._create_Vtable_globals   （46ms/次）
  66.6s       238007   HandlesImports._build_stub_index
  63.0s    317868145   str.startswith
  38.4s    175751378   str.endswith
  ...
  ── 仅 isdir + listdir + join/splitroot/endswith ≈ 850s ≈ 总时长的 37%

一、_build_stub_index 的零 syscall 快路径（HandlesImports + Phase2Translator）
    它由 _TryLoadStructFromStub 的**每次索引 miss** 调用（238k 次），每次都要
    2× os.path.isdir + 2× os.listdir + 全量 endswith/join 重拼文件集合 ——
    这正是上面 isdir 723k / listdir 479k 的主要来源。
    改为：写入方显式置脏（ImportHandle.MarkStubSetDirty），未置脏时直接返回。
    置脏点：① 每个文件翻译入口（_translate_file，顺序与 worker 模式皆按文件粒度
    覆盖）② 写 temp/<sha1>.stub.ll 之后 ③ 注册 include 写 output/<sha1>.stub.ll
    之后。索引建完即清脏。语义：增量重扫、output 覆盖 temp 全部不变，只是把
    "集合是否变化"由目录扫描改为写入方免费告知（编译进程内 stub 只增不改）。

二、_create_Vtable_globals 的 O(类数 × 函数数) → O(函数数)
    原实现对每个候选类都遍历一遍 self.functions 找 "{ClassName}." 前缀且非
    declare 的函数；改为一次性预计算"非 declare 函数名的全部点分前缀"集合，
    每类只做一次集合查询。判据等价（startswith(prefix) ⟺ prefix 在点分前缀集）。

重编后请再抓一次 profile 复核收益；下一梯队热点是 _generate_structs
（268.6s tottime / 35k 次调用）与 _parse_llvm_type（3.5M 次调用）。
 2026-09-29 14:36:57 +08:00
TermiNexus f1e7fd6c28 perf(tpc): _LookupStubFuncType 的目录计数按目录 mtime 缓存，去掉每次调用的全量 listdir 
类别：纯提速（判定结果不变）。原实现每次调用都要

  sum(1 for f in os.listdir(output_dir) if f.endswith('.stub.ll'))
  sum(1 for f in os.listdir(temp_dir)   if f.endswith('.stub.ll'))

只为构造一个"stub 是否新增"的签名；本函数位于每次跨模块函数/方法查找的热路径
（20 个调用点），开销 = O(目录文件数) × 调用次数，与编译工作量无关，工程越大越亏。

改为 ImportHandle._CountStubFilesInDir(DirPath)：同一「目录 + 目录 mtime_ns」
只 listdir 一次，mtime 命中即复用上次计数（每目录一次 os.stat 代替一次
os.listdir + 全量 endswith 判定）。
判据：stub 目录只增不改、且由主进程在批次之间写入 ⇒ 只有目录条目增删才会改变
计数，而 Windows/NTFS 在条目增/删/改名时会更新目录 mtime。
取不到 stat（目录不存在/权限）时不写缓存、退化为每次实算。
计数仍是权威签名，缓存只决定"要不要重新 listdir"，不改变任何判定结果
（增量重扫、output 覆盖 temp 的语义逐字不变）。
 2026-09-29 14:32:39 +08:00
TermiNexus f4c8c48748 fix(tpc): 函数声明创建全部收口到唯一幂等入口，消除 DuplicatedNameError 裸抛 
类别 a（编译器缺陷）+ b（机制漏豁免）。报错：翻译 lib\core\Gen\Expr\ExprGenName.vp
失败，报文只有名字 dddc595175f00c66.ExprGenAttr.find_global_in_module
⇒ llvmlite DuplicatedNameError（NameScope.register 对 GlobalValue
deduplicate_name=False，同名 global 再建必抛，__str__ 只回名字）。

根因（已取证，非猜测）：
- llvmlite Module 里 `scope`（NameScope，注册/去重）与 `globals`（OrderedDict）
  是两套结构；`add_global` 只在构造时写入 ===> 「名字已在 scope._useset、
  但 globals 查不到」这一状态一旦出现，任何"先查 globals 再建"的守卫都会失效。
- 该状态由**清理不完整**制造：删旧名时只删"对象真名 existing_func.name/old_name"，
  而字典键/目标名（func_name / MangledName）仍留在 scope._useset。
  别名注册（Gen.functions[短名] = 名为全名的对象）恰好让二者不同名。
- 另有若干创建点只看 Gen.functions、完全不看 module.globals（裸建 ir.Function），
  只要 module.globals 已有同名声明就裸抛 DuplicatedNameError。

本次收口（函数声明创建的唯一入口 = BaseGen._CreateOrReuseFuncDecl）：
1. BaseGen._CreateOrReuseFuncDecl：新增"名字被非函数 global 占住"分支，把冲突
   双方（类型 + repr）报出来，替代原 llvmlite 只给名字的裸抛。
2. 清理不完整处补全为「同时清 真名 + 目标名」：
   - HandlesImports.py 模板 declare 装载（clearing func_name 之外还清 existing_func.name）
   - HandlesFunctions._replace_function_decl（clearing {old_name, MangledName}）
   - 其 except 对 FailFastError 改为上抛（不再回退成复用旧声明）
3. 裸建 ir.Function 的创建点改走唯一入口（module.globals 同名则复用、
   签名冲突/非函数冲突则 fail-fast）：
   - HandlesExprCall._HandleStaticMethodCallLlvm（{sha1}.Class.Method）  ← 本现场形态
   - HandlesExprCall._HandleMethodCallLlvm 的 class_sha1 回退分支
   - HandlesExprCall._try_declare_c_lib_func / HandlesExprBuiltin._try_declare_c_lib_func
   - HandlesAssign 模块级全局赋值处的函数声明
   - HandlesImports.__before_init__ 声明（原查 NewFuncName 却建 MangledName）
   - HandlesFunctions._EmitFunctionLlvm（补登记 module.globals 已有声明，
     使既有的签名修复路径生效，而不是裸建撞名）

行为等价性：上述各点原先"撞名"时必然抛 DuplicatedNameError（即必失败），
收口后要么复用同一符号、要么 fail-fast 报出两侧签名/冲突类型，无静默降级。
 2026-09-29 13:50:44 +08:00
TermiNexus 8c831a38d3 fix(tpc): 局部 str*/str|t.CPtr 注解不再被压平成 i8*（补 PtrCount<=1 豁免） 
类别 b（机制漏豁免）：`TypeInfo.IsStr` 对**任何** CChar + 指针层都为真，
局部 AnnAssign 处却无条件把 PtrCount 压成 1，导致 `argv_arr: str*` 被声明为
i8*，而同名模块级全局 `_argv: str*` 走 HandlesAssign._EmitGlobalAnnAssignLlvm
的 FromNode 得到 i8**，于是 `_argv = argv_arr` 被
「指针隐式转换已禁止（层数不同）：i8* → i8**」拦下（includes/sys.vp:114、
_init_argv_posix 同款 L148）。

同一规则在 HandlesFunctions.py:599 / 690 / 722 / 1434 / 1514 / 1602 / 1662 与
HandlesImports.py:1440 / 1542 都已带 `IsStr and PtrCount <= 1` 豁免（注释写明
"str | t.CPtr 合并后 IsStr=True 但 PtrCount=2（i8**，如 argv 数组），不能压平"），
唯独 HandlesAnnAssign.py:452 漏了这一条 —— 本次补齐：只压平 PtrCount<=1，
`str*` / `str | t.CPtr` 保持 i8**；_str 影子结构与 var_ptr_element（8 字节步长）
标记仍照旧执行。

判据（不猜）：
1. TPV 参考实现产物 Test/SysLibTest/.tpv_build/temp/0c/0cc16828640f94b7.ll：
   `@"0cc16828640f94b7._argv" = global i8**`、_init_argv_win32 内
   `alloca i8**`（argv_arr）、`store i8** %x, i8*** @"..._argv"` —— 局部与全局
   同为 i8**。
2. TPC 全局侧 FromNode 对 `str*` 给出 PtrCount=2（CChar + str 的 1 层 + CPtr 的 1 层）。

重编即可验证 sys.vp 第 84/114 行一致。
 2026-09-29 13:33:54 +08:00
TermiNexus a6c9003a19 fix(tpc): struct body 解冻改用 llvmlite 公开属性 elements（原 _elements 是空操作） 
类别：a 编译器缺陷（机制漏豁免：错误的"解冻"字段名使所有 body 重建路径失效）。

现场（连续多轮复现）：TransPyV Generator.vp:200
`self.ExprGenFstr = SubExprGenFstr` 报「指针隐式转换已禁止（层数不同）：
%"a7b68c79f39cb4d3.ExprGenFstr"* → i8**」，[成员槽来源] 显示
class_members[Generator] 下标 11 声明槽类型**正确**，而布局
'47382dc8277c9d28.Generator' 的 elements[11]=i8**。

取证（已核对全部产物与共享符号表，排除"来源侧退化"）：
- TransPyV/output/*.stub.ll 与 temp/47382dc8277c9d28.stub.ll 里
  %"47382dc8277c9d28.Generator" 的 slot11 全部是 %"a7b68c79f39cb4d3.ExprGenFstr"*，
  **没有任何 stub 含 i8**；
- 共享符号表（temp/_shared_sym.json → symbol_table_bytes）里
  Generator.Members['ExprGenFstr'] = CTypeInfo(BaseType=CStruct('ExprGenFstr'),
  PtrCount=1, IsStruct=True)，也**正确**。

真根因：llvmlite 本版本 IdentifiedStructType 的字段是**公开属性 `elements`**
（types.py: `self.elements = None`；`is_opaque` = `elements is None`；
`set_body` 仅在 `elements is not None` 时抛 "already defined"）。而本仓所有
"清除 body 以便重建"的路径都写 `st._elements = None`（不存在的属性）⇒ **空操作** ⇒
⇒ `if struct_type.elements is None` 恒假 ⇒ set_body 永不执行 ⇒ 早期冻结的错误布局
（如 i8**）无法被任何后续权威重建覆盖：
  · StructGen Step 4 逐元素校验已判定不一致（_slot_types_ok=False），清空失败 ⇒
    既不能 skip 也不能重建 ⇒ 错布局被静默保留；
  · HandlesClassDef 的本地定义权威重建点（class_members 已重建为正确类型后）
    同样无法刷新 body。
两处叠加正是"class_members 正确、布局却是 i8**"的稳定现象，也解释了此前
TypeGenCDef(槽3) / ExprGenFstr(槽11) 在不同构建里交替出现（取决于谁先被冻结）。

修复：四处解冻改为写公开属性 `elements`：
  · StructGen.py Step 4 前置校验失败后的清空；
  · StructGen.py sha1 全名 key 的 struct 清空；
  · StructGen.py T* 占位清空；
  · HandlesClassDef.py @t.NoVTable 本地定义点的清空。
清空后 is_opaque 恢复为真 ⇒ _TryLoadStructFromStub（declare 侧权威 body）或
class_members 重建可真正 set_body。
 2026-09-29 13:13:17 +08:00
TermiNexus 9d8aedec4a fix(tpc): 函数声明创建收口到幂等入口 _CreateOrReuseFuncDecl；清理 DDEBUG 探针 
类别：a 编译器缺陷（根因修复）+ 调试探针移除。

现场：翻译 CallGenFd.vp 时抛 llvmlite.ir._utils.DuplicatedNameError:
'5d84ea579d83ef73.CallGenFd._translate_fakeduck_call'（llvmlite 的
NameScope 按名字去重，GlobalValue.deduplicate_name=False ⇒ 同名 global
建第二次必抛，且报文只给名字、不给两侧签名）。

根因：BaseGen._get_or_declare_function 建完 ir.Function 后**只加入
module.globals**（llvmlite 自动）而**未登记 Gen.functions**；而
HandlesFunctions._EmitFunctionLlvm 的 need_new 判据只看 Gen.functions
（`MangledName not in Gen.functions`）⇒ 同一名字再建一次 → DuplicatedNameError；
该处 except 又把它吞掉（非 strict 模式只 LogWarning）→ 函数始终没进
Gen.functions → 后续其它创建点（FuncGen._get_or_declare_func /
get_or_declare_c_func，同样只查 self.functions）再建 → 异常从别处逃逸到
Phase2Translator。

修复：
1. BaseGen 新增 _CreateOrReuseFuncDecl(name, func_type) —— 函数声明创建的
   唯一幂等入口：module.globals 已有同名函数且**函数类型结构串相同**则复用
   （并补登记 Gen.functions；FunctionType 无 __eq__，只能比 str）；
   类型不同则 fail-fast 报出两侧签名（declare/define 分裂的真因），
   绝不静默复用错签名（调用点会按错签名传参）。
2. _get_or_declare_function 改走该入口（顺带补登记 Gen.functions）；
   FuncGen._get_or_declare_func / get_or_declare_c_func 改走该入口；
   HandlesFunctions 定义路径改走该入口，且该处 except 对 FailFastError
   直接 re-raise（不再吞）。
3. 清理遗留调试探针（含 sys.exit(1)）：BaseGen 三处 [DDEBUG]
   （_get_or_declare_function 双点 / _mangle_func_name 前导点与结果双点）、
   HandlesExprAsm 两处 [DDEBUG_ASM]、HandlesExprCall 一处
   [DDEBUG] _HandleClosureCallLlvm。
 2026-09-29 13:00:11 +08:00
TermiNexus fd212b3ff8 fix(tpc): 联合强转 (T|t.CPtr)(x) 及其属性访问失败改为 fail-fast（附判定依据） 
类别：b 机制漏豁免（把静默 return None 改成响亮失败并带证据）。

现场：TransPyV lib/core/Gen/Expr/ExprGenBase.vp:360 的
v = (ast.Expr*(node)).value 报“赋值表达式 'value'（Attribute 形态）编译期
求值为空”，而同一函数前三条 (ast.Assign/AnnAssign/AugAssign*(node)).value
同款写法正常 ⇒ 无法从报错看出是哪一步丢了类型。

两处静默返回改为 fail-fast（均只对该强转形态生效，其余路径行为不变）：
1. HandlesExprCall._HandleTypeUnionCastLlvm：目标类型串解析失败（原为
   _vlog().warning + return None）。新增 _DescribeUnionCastFailure 取证：
   MergeTypes 返回值/ToString()/异常、_ExtractTypeStrFromUnionBinOp 结果，
   以及联合中每个操作数在符号表与类登记表（Gen.structs / _struct_sha1_map /
   class_sha1_map）的命中情况 —— 直接指认“基座类名没被当成类”还是
   “CPtr 标记侧解析失败”。
2. HandlesExprAttr._handle_attr_call_result：(T|t.CPtr)(x).attr 的 5 个
   return None（基座求值为空 / 非指针 / find_struct_by_pointee 未命中 /
   结构体不透明 / 成员偏移取不到）改为 _FailFastAttrCallBase，报文含联合
   基类名与三家登记表命中、被指类型 elements、class_members 项数与目标成员偏移。

原因：(T|t.CPtr)(x) 只可能来自指针强转（parser 把 (T*)x / (T*)(x) / T*(x)
统一产成该 Call），必须有值产出；静默丢弃会让整条表达式被判为空，把
“类名解析失败 / 结构体不透明 / 成员偏移取不到”三种不同根因混成同一条报文。
 2026-09-29 12:23:54 +08:00
TermiNexus 7167703ca7 fix(tpc): 降级判据改用「注解形态 + 解析结果形状」，放在字段类型唯一漏斗 
上一版拦截失效的原因（实测）：`class_member_annotations` 全仓**只被声明与读取、从未被
写入**（Step 2 一直是空转），故依赖它的 `_HasDegradedMemberTypes` 恒为 False。改法：

1) SymbolUtils 新增两个**形状判据**（纯判定，不做类型解析）：
   - IsI8DoublePtrType(T)：是否 i8 系两层指针（`i8**`）= `T | t.CPtr` 在 T 类型丢失后
     退化成的形状；
   - IsClassRefPtrAnnotation(Ann)：注解是否「指针包装的类引用」（rawptr[Mod.Class] /
     Mod.Class | t.CPtr；内层为非 t/c 模块的 Attribute 或首字母大写裸名）。
2) HandlesBase.CollectAnnAssignMember（字段类型的**唯一漏斗**，覆盖本地类 /
   跨模块 .vpi / 嵌套类三条写入链）新增硬判据：注解是类引用指针 **且** 解析结果正是
   `i8**` ⇒ 必属类型信息丢失，当场 fail-fast，并打出 CTypeInfo 全字段（BaseType/
   PtrCount/IsStruct/IsTypedef/IsEnum/Name）与内层名的符号表条目标志。此前的
   `_CheckPtrAnnotationKeepsClass` 只看"void 基座且无类身份"，而现场这条链**带 Name/
   IsTypedef**（Attribute 分支的 typedef 出口 → BaseType=CVoid 但 Name=类名），正好漏过。
3) StructGen 删除依赖那张空表的 `_HasDegradedMemberTypes` / `_IsI8DoublePtr` /
   `_IsClassRefPtrAnnotation` 及 set_body 前的拦截（改由漏斗处兜住，不留死代码）。

现场：Generator.vp:200 `self.ExprGenFstr = SubExprGenFstr`
  → 布局槽 elements[11]=i8** 而声明 %"a7b68c79f39cb4d3.ExprGenFstr"*
 2026-09-29 12:04:20 +08:00
TermiNexus dab0823f5c fix(tpc): 收紧「类身份」判据 + REnum 变体载荷解析失败不再被吞 
承接 02d89b09：上一版判据"BaseType 是 CVoid ⇒ 类型信息丢失"**误伤 REnum** ——
REnum 类型条目本身 `BaseType=None`，`T | t.CPtr` 合并时 `_MergeAllComponentTypes`
末尾会把空 BaseType 默认填成 CVoid，但 IsRenum/IsStruct/Name 齐备，`_ctype_to_llvm`
仍能解析出 `%<sha1>.T*`。于是合法注解 `Pointee: rawptr[LLVMType]`（REnum 变体载荷）
被打成致命错误，异常又在此处被上层吞掉 ⇒ 变体只剩 __tag。

两处修正：
1) HandlesBase._CheckPtrAnnotationKeepsClass：判据收紧为「BaseType 是 CVoid **且
   没有任何类身份**（IsStruct / IsRenum / IsEnum / Name 全空）」才失败。
2) HandlesImports REnum 变体载荷注册：历史上 `CollectAnnAssignMember` 的异常被上层
   吞掉、`parsed` 为 None 时静默跳过 ⇒ class_members 只剩 __tag、变体循环中断
   （现场同前缀 structs 键只有 LLVMType_Int / LLVMType_Ptr，源顺序其后还有
   Func/Array/Struct/…），进而使变体构造丢载荷、match 捕获绑不上。现改为：
   - 只把 AnnAssign 当载荷声明（pass / docstring 合法跳过，如 `class Void: pass`）；
   - 解析抛异常 ⇒ fail-fast 并带上原异常（拒绝留下只有 __tag 的成员表）；
   - 解析返回 None ⇒ 同样 fail-fast。
 2026-09-29 11:24:57 +08:00
TermiNexus 53bde9157e fix(tpc): REnum 变体嵌套结构体按需补发 + 模式捕获绑不上即 fail-fast 
a 编译器缺陷：导入模块侧 stub 只声明主 REnum（`%"…LLVMType" = type {…}`），**不含**
变体嵌套结构体（`LLVMType_Ptr` 等）——它们由 `_EmitExternalClassDeclLlvm` 的 REnum
分支按主结构体布局就地生成。若本模块从未触发该 REnum 的外部声明发射：

  1) match 模式捕获（`case llvmlite.LLVMType.Ptr(pointee_cs):`）绑定静默为空 ⇒ case
     body 里引用的绑定名随后报"未定义名称"（现场 VpiReader.vp:1521 `pointee_cs`）；
  2) REnum 变体构造的载荷实参静默丢弃（只写 tag）—— 静默错码。

修法：
  - 新增 BaseHandle._EnsureRenumVariantStruct：成员缺失时按需补发（先试 stub，再按
    类 sha1 找到定义模块 .vpi 触发 `_TryLoadClassMembersFromPyi` → 内部即调
    `_EmitExternalClassDeclLlvm`）。
  - HandlesMatch._HandleRenumMatchLlvm：改用该助手；**模式捕获登记不全即 fail-fast**
    （报出变体名、class_members 项数、structs 命中与同前缀键），绝不让绑定名留到
    取名时才炸。
  - HandlesMatch 非 REnum 兜底分支：MatchClass 含捕获时改为 fail-fast，并列出判据
    （IsEnumMember/EnumName/IsRenum/IsStruct/IsEnum），直接暴露"外层 REnum 判定为何
    未成立"。
  - HandlesExprCall._HandleREnumConstructLlvm：载荷实参存在而嵌套结构体缺失时补齐，
    补不上则 fail-fast（拒绝产出"只有 tag 没有载荷"的值）。
 2026-09-29 11:21:19 +08:00
TermiNexus 02d89b0900 fix(tpc): 字段解析「内层是类却成通用指针」当场 fail-fast（降级源头定位） 
承接 b8ed33a2 / 7fb0e498：前两者修的是**结果**（错位 body），本次收**源头** ——
class_members 在某个早期 pass 被解析出 i8**（void 基座 + 2 层），随后被冻进
struct body。CollectAnnAssignMember 是字段类型的唯一汇总点，在此加判据式 fail-fast：

判据（只拦"必属类型信息丢失"的组合）：注解是指针包装（rawptr[T] / t.CPtr[T] /
裸名 CPtr[T] / `T | t.CPtr` 联合）且其**内层节点（Name/Attribute）的名字在
Gen.structs 或 Gen._struct_sha1_map 中有类定义**，而解析出的 BaseType 却是
t.CVoid ⇒ 必定是解析路径把类丢了，响亮失败并附完整判据：
  解析结果 BaseType/PtrCount/IsStruct/IsTypedef/Name
  符号表[内层名] => IsTypedef/BaseType/PtrCount/IsStruct/IsRenum/IsModuleAlias/IsEnumMember
  Gen.structs 命中 / _struct_sha1_map 命中

放行：rawptr[rawptr] 这类本就 void 基座的多层指针、模块名、泛型特化实参（内层非
Name/Attribute）—— 不误伤合法写法。
 2026-09-29 00:21:39 +08:00
TermiNexus c49dc1d915 fix(tpc): 类型静默降级改 fail-fast + 成员槽写入失败附来源明细 
a 编译器缺陷：类型信息缺失时静默兜底会掩盖上游根因，兜出来的"看着合理"的类型
（如 i8**）又会让下游报出与真因无关的错。按既定铁律改为响亮失败：

1) HandlesImports._parse_llvm_type：被指类型是具名聚合（%...）却在
   create_structs=True 下取不到结构体时，原静默 `return PointerType(i8)` ——
   结构体指针被悄悄变成通用指针，外层再套一层即成 i8**。改 fail-fast。
   （create_structs=False 属"尚未加载"，非异常，保持原样。）

2) HandlesTypeMerge._HandleSubscript：新增判据自洽守卫 —— base 是指针标记
   （rawptr / t.CPtr / 裸名 CPtr / 别名）而 IsPtrSubscriptNode 未命中时，
   历史上会落到 CollectAll 当"数组下标"解析、静默产出「基座 void + 多层指针」
   （i8**）。现 fail-fast（判据分裂即内部不变量被破坏）。

3) HandlesAssign._HandleAttributeStoreLlvm（`self.字段 = 值`）：成员槽写入失败
   时追加「成员槽来源」明细 —— class_members 声明侧（项数/base/下标/声明槽类型）
   + 布局侧（struct IR 名/元素数/elements[offset]）+ structs 键数与是否同一对象，
   使"声明侧退化"与"布局侧退化"一眼可分，杜绝再靠猜。

现场：TransPyV/App/lib/core/Gen/Generator.vp:193 `self.ExprGenConst = SubExprGenConst`
  → 指针隐式转换已禁止（层数不同）：不能把指针类型
    %"cfd1f3d0d7e87fea.ExprGenConst"* 隐式转为 i8**
 2026-09-28 23:59:29 +08:00
TermiNexus 78c5155de9 revert(tpc): 回滚 51de3b6d 的 [DIAG-decl] 临时诊断 
「跨模块函数形参退化成 i32*」（constant_get_str_val / function_get_name 第 0 形参
i32*）一族已由 1c1f78e7 定位修复（同名枚举成员遮蔽类定义，判据按 IsEnumMember
区分），探针使命结束，整体移除：
  - FuncGen._RecordDeclFrom / _DescribeI32ParamDiag 及两处调用点
  - _adjust_args fail-fast 报文中的 _diag_extra 拼接
  - BaseGen._get_or_declare_function 入口记录点
  - HandlesBase.GetOrCreateFuncDecl 入口记录点
 2026-09-28 23:23:02 +08:00
TermiNexus 833e8c7c33 fix(tpc): 识别点号写法的 REnum 变体构造 mod.REnumClass.Variant(...) 
a 编译器缺陷（同一语义两种书写的判据不一致）：HandlesExprCall 的跨模块 REnum 变体
构造分支只判 `isinstance(Node.func.value, ast.Name)`，即只认裸名写法
`LLVMType.Ptr(x)`；**点号写法** `llvmlite.LLVMType.Struct(fields, fcount, name)`
（Node.func.value 是 Attribute）漏掉，落到下方"模块函数 Struct"路径 ⇒
  · 返回类型被当成普通函数返回值（实为 boxed 变体构造指针）；
  · 实参少一个 pool（arity 也不对）。
现场：ClassGenDef.vp:116 的 `*existing.Ty = llvmlite.LLVMType.Struct(...)`
报"不能把指针类型 %LLVMType* 隐式转为值类型 %LLVMType"。

补齐：新增同口径分支——Node.func.value 为 Attribute 时，按其 attr（REnum 类名）
在符号表（先试 f"{ModulePath}.{attr}" 再试裸名）取 IsRenum 条目，命中
RenumVariants 即走 _HandleREnumConstructLlvm（与裸名分支同一实现）。与
includes/llvmlite/__types.vp:195、__builder.vp:173 的既有用法一致。
 2026-09-28 23:14:08 +08:00
TermiNexus 1c1f78e7b3 fix(tpc): 修正枚举判据——按 IsEnumMember 区分成员/类型（bb05a157 判反了） 
a 编译器缺陷：bb05a157 用 `not Entry.IsEnum` 排除"枚举类型"，但现场实测枚举
**成员**条目的标志组合是
    IsEnum=True + IsEnumMember=True + BaseType=CEnum
（成员的 IsEnum 也被置真）⇒ 成员被误判成枚举类型，`rawptr[Constant]` 落 i32*，
`constant_get_str_val` 形参再次退化成 i32*。

正确判据（两处同源）：
  枚举**类型** = IsEnum and not IsEnumMember ⇒ 走枚举分支（宽度 i32 等）
  枚举**成员**（IsEnumMember）⇒ 不是类型 ⇒ 让位给类定义（"有类定义 ⇒ 是类"）

现场证据（51de3b6d 的 [DIAG-decl] 报文，随 Traceback 输出）：
  实参类=5df907d3a02a0bac.Constant | structs=有 |
  _struct_sha1_map=5df907d3a02a0bac | class_sha1_map=5df907d3a02a0bac |
  symtab[IsStruct=False, IsEnum=True, IsEnumMember=True, Base=CEnum] |
  声明函数类型=i8* (i32*) | 声明来源=..._EmitExternalFuncDeclLlvm <- _get_or_declare_function

修后 `ResolveAnnotationType(rawptr[Constant])` 得 CStruct/1 ⇒ _ctype_to_llvm 取
structs['Constant'] ⇒ 声明变为 i8* (%"5df907d3a02a0bac.Constant"*)，与实参同型。
 2026-09-28 22:44:20 +08:00
TermiNexus 51de3b6dcf chore(tpc): [临时诊断] 声明来源 + i32* 形参判定依据并入 fail-fast 报文 
只为定位"跨模块函数形参退化成 i32*"（现场 function_get_name 第 0 形参 i32*，
实参 %"46c7dc5230ea5a52.Function"*）。静态排查已穷尽：_ctype_to_llvm /
_type_str_to_llvm 产生 i32* 的出口只有「BaseType 退化成 i32 + PtrCount=1」
（含 CTypeInfo.ToString() 的 'CInt *' → i32*）与「IsEnum + Name + PtrCount=1」，
离线复现不出，需要运行时证据。

做法：把判定依据直接拼进 FailFastError 报文，使其随 Traceback 一起被看到：
  [DIAG-decl] 实参类 / structs / _struct_sha1_map / class_sha1_map /
              symtab 标志 / 声明函数类型 / 声明来源（创建者调用栈）
并在四个声明创建点记录首个创建者：
  FuncGen._get_or_declare_func / get_or_declare_c_func、
  BaseGen._get_or_declare_function、HandlesBase.GetOrCreateFuncDecl（会替换声明）。

定位完成后整体回滚（连同记录点）。
 2026-09-28 22:20:09 +08:00
TermiNexus bb05a157a6 fix(tpc): 收紧「有类定义 ⇒ 是类」判据：排除枚举类型本身 
a 编译器缺陷（我上一轮 61f074ff / 3ca46c01 引入的过宽判据）：判据用的
_struct_sha1_map 是 _build_struct_sha1_map 按 .vpi/.pyi 里**全部 ClassDef** 建的
⇒ **枚举类**（class ASTKind(t.CEnum)、class LogLevel 等）也在其中。于是
`x: ASTKind` 这类枚举注解被当成结构体建成 opaque struct，与「枚举宽度 = i32」
错位，现场表现为 i32 ↔ 结构体互换：
  AttributeError: IntType object has no attribute is_opaque
（llvmlite builder.store / LoadInstr 把 i32 值当指针用）。

收紧为判据分工（两处同口径）：
· HandlesTypeMerge._GetCTypeInfoInternal 的 Name 分支：Entry.IsEnum ⇒ 枚举类型，
  不进「类定义」分支（走下方 IsEnum 分支，宽度 i32 等）；
· BaseGen._get_or_create_struct：_known_class_name 追加 and not Entry.IsEnum。

「裸名被枚举**成员**占住」（Entry.IsEnumMember，如 ast/base.vp 的
Constant: t.State vs ast/exprs.vp 的 class Constant）仍让位给类定义 —— 这正是
原修复要解决的那一类，不受影响。
 2026-09-28 21:57:21 +08:00
TermiNexus e6451a077e fix(tpc): 继承展平沿继承链补真实字段名（消除 __inherited_N 占位名） 
a 编译器缺陷：泛型基类的继承字段在导入侧展平时名字丢失。父类是泛型特化
`GSListNode[ParamNode]`，其特化体不在任何 .vpi 中 ⇒ 按特化名加载必落空 ⇒ 占位符
路径按 struct 槽位数补 `__inherited_N`：偏移对、**名字丢**。于是继承字段的属性访问
找不到字段（现场 `[fast-fail] 属性 Next 在类 ParamNode 中找不到
（class_members=[__inherited_0, Ty]）`）。

语义修正：新增 _ResolveInheritedFieldNames —— 按**声明顺序**沿继承链取父类声明里的
字段名；父类是泛型特化 `X[Arg]` 时回退用**模板名** X 加载其成员（模板声明了字段名，
如 linkedlist.vp:265 `GSListNode[T]: Next: T*` 的 Next），这正是编译期唯一可信的
名字来源；与 DeclarationGenerator._get_inherited_members（stub 端取模板成员）、
BaseGen._get_or_create_struct 的 `_struct_sha1_map` 拼名规则同一条"类名 → 模板/模块"
规则源。名字取不到才退回占位名（仅保证偏移）。

同时修正占位符配对的槽位起点：有 vtable 指针时首元素是 vtable，上面已把它从
_num_elements 扣掉，配对结构体元素必须同步右移一位（原实现从 elements[0] 起取，
会把 vtable 指针的类型当成第一个继承字段的类型）。

结果：展平表直接是 `[("Next", <槽位类型>), ("Ty", ...)]`，属性访问是普通表命中，
不再依赖任何查找期回退。
 2026-09-28 21:46:30 +08:00
TermiNexus 61f074ffa4 fix(tpc): Name 注解路径的类/枚举同名判据补齐 _struct_sha1_map 
a 编译器缺陷：HandlesTypeMerge._GetCTypeInfoInternal 的 ast.Name 分支在「类名与
枚举成员同名」时只查 Gen.structs，漏了 Gen._struct_sha1_map（跨模块类只登记了
类名→模块 sha1、本模块尚未建出结构体）。同文件的 Attribute 分支（L241-269）与
HandlesClassDef._HasClassDefinition、TypeConvert._type_str_to_llvm_base 的
同一判据都是「structs 或 _struct_sha1_map」，Name 路径独缺，属判据分裂。

现场：rawptr[Constant]（includes/ast/exprs.vp:59 accessor，class Constant 声明在
同文件更后面）在导入侧解析时，先命中平坦符号表里的枚举成员 Constant: t.State
（ast/base.vp）→ 返回枚举 → 与 t.CPtr 合并后经 _ctype_to_llvm 的 IsEnum 分支
（枚举名未登记 ⇒ 宽度退化为 i32）得 i32*，与调用点实参 %"<exprs_sha1>.Constant"*
分裂 → FuncGen._adjust_args 报「指针隐式转换已禁止」。

补齐后 BaseType=CStruct(Constant)，_get_or_create_struct 按 _struct_sha1_map 拼出
"<exprs_sha1>.Constant"（BaseGen.py:527-528），与声明端/实参同一结构体对象。
 2026-09-28 19:40:06 +08:00
TermiNexus b3f72d675b fix(ctx): 方法体编译失败路径也复位「当前方法」上下文，修 self 被按内层特化类解析 
现象：编译 ExprGenFstr.translate_joined_str 时 self.Gen 被按 list[cfc4ca8da95a30e1.AST*] 解析 → 属性在类中找不到（连带错误）。

链路：parts.get(pi) 触发泛型特化按需补全（HandlesExprCall._try_complete_generic_specialization）→ 内层 list[...] 方法发射时 _EmitFunctionLlvm 先置 _CurrentCpythonObjectClass = 内层类（HandlesFunctions:1978）→ 方法体编译失败只 re-raise，末尾的类名/var_struct_class 复位被跳过 → 上层调用点**吞掉**该异常继续编译外层方法，于是外层 self.X 全按内层类解析、后续指令也会误插进内层函数的块。

两处修复：① _try_complete_generic_specialization 的 except 里同时复位 Gen.builder/func 与 _CurrentCpythonObjectClass/Gen._current_class_name（该点会吞异常，必须自己收尾）；② _EmitFunctionLlvm 的失败路径在 re-raise 前复位 Gen._current_class_name / _CurrentCpythonObjectClass / var_struct_class / global_struct_class（对所有吞异常的调用点都成立）。
 2026-09-28 16:52:03 +08:00
TermiNexus 49ff1b995f fix(cast): 显式指针 cast 一律放行（按 bitcast 重解释）+ MemoryOps 改用 vast 解析器模块 
① 新增 _IsExplicitPtrCastNode：值节点是写明的指针转换调用（t.CPtr(x)/CPtr(x)/c.CPtr(x)/rawptr[T](x)/t.CPtr[T](x)/(T*)x/T*(x)）时，_ClassifyPtrImplicitConvert 直接放行（用户规则「显式转换都可以」），调用方按既有 bitcast 重解释；非 cast 调用（MemBuddy(x)/list[X](x)/foo(x)）不受影响。

根因：includes/_list.vp:60 的 elem_ptr: T | t.CPtr = t.CPtr(地址) 在 list[X*] 特化下 T|t.CPtr = X**（T 本身是指针），而 t.CPtr(...) 的值是 i8* ⇒ 被判「层数不同」，与报错自己给的「如需转换请显式 cast（如 t.CPtr(...)）」建议自相矛盾（ExprGenFstr.vp 编译失败的 2 条 elem_ptr 报错）。

② MemoryOps.py 的 import ast 是标准库 —— 但 TPC 全部源码由 vast 解析，节点类为 lib.vast.Nodes.*，与标准库 ast 互不兼容 ⇒ 该文件所有节点类型判据对 Viper 源码静默失效（_value_node_of 子表达式下沉、_CtorCallStructType 构造物化豁免、以及新增的 cast 判据都不生效）。改为 import vast as ast，一并修复。
 2026-09-28 16:48:52 +08:00
TermiNexus 809f9d08fa feat(len): len() 对「非 i8 裸指针 / 无 __len__ 的 struct」改为 fail-fast（对齐 TransPyV） 
旧实现：非 i8 裸指针（如 []T 形参实为 T*）静默返回常量 0；struct 无 __len__ 时回落 strlen —— 两者都用假长度掩盖错误。

新口径（两侧逐字一致）：定长数组/数组指针 → 常量 N；i8*（str/bytes）→ strlen；带 __len__ 的结构体 → 调 __len__；其余一律编译期 TypeError。

新增 _LEN_SUPPORTED_HINT 共享提示语 + _FailFastLenUnsupported 出口（含 行:列 + 源码片段 + 正确做法）。HandlesExprCall.py 为同源死代码副本，一并同步语义未删。
 2026-09-28 15:53:02 +08:00
TermiNexus d7158bd336 feat(cast): 指针隐式转换新规则 + None 可隐式转任意类型 + 诊断错位修复（9 文件） 
MemoryOps._ClassifyPtrImplicitConvert：同类型放行；层数不同禁；任一侧通用指针(i8*)放行；皆非通用按被指类型（非基本类型禁、基本标量按位宽无损）；指针与非基本值互换禁

_IsNoneValue 收敛：AST None 常量 或 指针型 null 常量 → 放行任意目标（指针目标给 null，非指针目标给零值）；整数 0 不误命中；短路口覆盖 9 处禁令

诊断：新增 BaseGen._DescribeValueNode（子表达式下沉 + 有符号列号 + 源码片段），9 处禁令统一使用，不再打印外层 Assign 与 4294967295 列号

注：TPC 侧规则③比 TPV 更严（指针→非基本值恒禁），可能与既有按值回读冲突；待实机编译确认后再统一两侧口径
 2026-09-28 15:10:39 +08:00
TermiNexus 35de6321f6 refactor(return): 移除 @c.CReturn 多返回值处理器，只保留 -> tuple[ty1, ty2, ...]，遇到 CReturn 一律报错 
DeclarationGenerator：tuple[...] 分支逐字保留（仅 CReturnTypes 机械改名 MultiRetTypes），装饰器分支改为 SyntaxError，报文含函数名与“请改用 -> tuple[ty1, ty2, ...]”提示

HandlesAssign（a, b = f() 解包路径）：删除装饰器收集分支并改为报错；tuple[...] 恢复与逐个解包逻辑逐字不变

HandlesFunctions：新增 _CRETURN_REMOVED_HINT 与 _RejectCReturnDecorator，在函数定义入口（_GetFunctionSignatureLlvm / _EmitFunctionLlvm）fail-fast——即使只有装饰器、没有 -> 注解，也不会让返回类型静默退化成 i32

HandlesImports：外部函数声明处同样报错，并删除下游已失效的 CReturnTypes 参数拼接死代码

HandlesReturn / HandlesFor / BaseTranslator：CurrentCReturnTypes 等机械改名（读写端一致，无行为变化）

includes/c.py：保留 CReturn 名字作墓碑（删掉会让 @c.CReturn 变成未知属性、可能被静默忽略），docstring 写明已移除并指路 -> tuple[...]；README 措辞同步
 2026-09-28 13:57:04 +08:00