 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
|
4d14334bd2
|
fix(LLVMCG): 成员表对齐改为「前缀锚 vs 尾部锚」按类型可写入性打分，修 Generator.vp:164 误报
类别：a 编译器缺陷（TPC 侧；修正 1776dfa6 / b06dac1d 的过宽判据）
现象：翻译 TransPyV/App/lib/core/Gen/Generator.vp 时 :164 `SubTypeGenErr.Gen = self` 报
「指针隐式转换已禁止：不能把 %"47382dc8277c9d28.Generator"* 隐式转为
%"6fbe68e8fca81223.TypeSpecArena"*」—— 目标类型是槽 41 的 Specs，而 Gen 的真身在槽 0。
判据：TypeGenErr 继承 TypeGenBase（41 槽）且只有 1 个自有字段 ⇒ body 42 槽；其成员表只含
['Gen'] 一项（**残缺前缀**，真身在 body 头部）。上一轮"尾部对齐"的前置校验（前缀数 == 父类
struct 槽数）在本例**巧合成立**：42 - 1 == 41 ⇒ 该表被锚到槽 41（Specs）⇒ 取到错误槽类型。
同族上一例为 Generator.vp:136（TypeGenMixin，已由 1776dfa6 挡住，但同类巧合仍会复现）。
修法：不再用"长度关系 / 父类槽数"去断言表的对齐方式（那是猜），改为**比较两个候选锚**的
逐项得分（判据与建 body / 存储侧同一套 `_MemberSlotAccepts`）：
· 前缀锚 `_BaseNow()` —— 展平表 / 残缺前缀；
· 尾部锚 `len(body) - len(表)` —— 仅自有字段（父类前缀未补齐，真身在 body 尾部）。
只有尾部锚**严格更高分**才采用它；同分/更低一律保持原行为（配对 → 下标法）⇒ 对既有正确
布局零行为变化，同时消除"巧合成立"的假阳性。命中尾部锚时每类留一次告警（报出两锚得分）。
验证：5 例冒烟全部通过 ——
A TypeGenErr（声明类型分别为通用指针 / Generator*，body 42 槽）.Gen → 0（修前 41）；
C AnnAssign 仅自有字段表 → target/annotation/value/simple = 8/9/10/11（尾部锚仍生效）；
D ExceptHandler 重名表 + 联合类型 children → name = 9（布局配对仍生效）；
E 自洽展平表 .value → 10（行为不变）；FuncGen.py py_compile 通过。
|
2026-09-30 00:39:06 +08:00 |
|
|
TermiNexus
|
1776dfa60a
|
fix(LLVMCG): 尾部对齐加「前缀数 == 父类 struct 槽数」前置校验，修正 Generator.vp:136 误报
类别：a 编译器缺陷（TPC 侧；修正 b06dac1d 引入的过宽判据）
现象：翻译 TransPyV/App/lib/core/Gen/Generator.vp 时 `SubTypeGen.Gen = self`（:136）报
「指针隐式转换已禁止（非基本类型）：不能把 %"47382dc8277c9d28.Generator"* 隐式转为
%"6fbe68e8fca81223.TypeSpecArena"*」。
判据（事实链）：
· SubTypeGen 静态类型 = rawptr[TypeGenMixin.TypeGenMixin]，Gen 字段声明在基类 TypeGenBase；
该 struct 41 槽：槽 0 = Generator*（Gen），槽 40 = TypeSpecArena*（Specs）。
· 抛错点 `_StoreWithCoerce` 用的是 **GEP 出来的槽类型**（TargetType = Ptr.type.pointee）
⇒ 报错里的 TypeSpecArena* 说明 "Gen 的偏移被算成了 40"（Specs 那一槽），而不是 0。
· 成因：b06dac1d 的「尾部对齐」在"成员表短于 body 字段区"时按 `len(elements) - len(表)`
求前缀数；TypeGenMixin 的表只有 ['Gen'] 一项（且其声明类型已退化成通用指针 ⇒
类型自校验被放行），于是被锚到 body 末尾 = 槽 40。
修法：尾部对齐加**必需的前缀校验**——前缀数必须等于**父类 struct 的槽数**（展平前缀就是
父类整份布局，含其继承链）；父类 struct 不可得（跨模块未加载 / opaque）时**不介入**。
TypeGenMixin：40 ≠ len(TypeGenBase)=41 ⇒ 不介入，落回下标法得 0（Generator*，赋值合法）。
（正面场景仍生效：AnnAssign 表仅 4 项自有字段、body 12 槽、父类 Stmt 8 槽 ⇒ 8 == 8。）
验证：冒烟两例——反例 TypeGenMixin.Gen → 0（修前 40）；正例 AnnAssign 仅自有字段表仍得
target/annotation/value/simple = 8/9/10/11；FuncGen py_compile 通过。
|
2026-09-29 23:58:09 +08:00 |
|
|
TermiNexus
|
bd92dfdadf
|
fix(LLVMCG): 成员表重名/联合类型字段不再打断布局配对，ExceptHandler.name 取到槽 9
类别：a 编译器缺陷（TPC 侧）
现象：翻译 TransPyV/App/lib/core/Gen/AsyncGenMixin.vp 时 `self._add_local(trans, hd.name)`
（:667）的第 2 个实参求值失败并终止编译。基址诊断给出的事实链：类 ExceptHandler
（%"831ce86a2fd82c0..." 即 astaux.vp）成员表 10 项 =
['parent','pool','lineno','col_offset','end_lineno','end_col_offset','children','children','type','name']
（'children' 重复一次），struct body 10 槽 =
[i8*, AST*, MemManager*, i32×4, list*, AST*(type), i8*(name)]，字段 'name' 计算偏移 = 10
⇒ 越界（正确槽 = 9）。
判据与修法（两条，均已写进代码注释与告警报文）：
1) 布局配对断链：成员表里 'children' 的声明类型是**联合类型折叠后的通用指针**
（`list[rawptr[AST]] | t.CPtr` ⇒ i8*），而 body 槽是具体指针（%"...list[...]"*）⇒
原配对只比 `is` / `str()`，在这一条断链，其后所有条目不再消费槽位 ⇒ 目标字段退化为
"base + 表内下标"（'name' ⇒ 1 + 9 = 10）。修：两侧都是指针时复用存储/建 body 侧同一
判据 `_MemberSlotAccepts`（通用指针 i8* 放行、具体指针按被指类型），标量仍走严格比较
——不引入新的过配对。修后 type = 8、name = 9 ✓。
2) 重名条目使长度判据失真：`_expected_count_pre = len(class_members) + vtable` 把重复项
也算一槽 ⇒ 误判"body 不完整"而用**带重复项的表**重建 body（本模块布局比其它模块多一
槽 ⇒ 跨模块 ABI 撕裂）。新增判据：表有重名**且** body 槽数恰等于「去重名数 + vtable」
⇒ 认定 body 已是权威布局（来自定义模块 stub），只报事实、不重建。
另在"未被 body 配对命中"的回退路径上，把"成员表含重名条目 + 表项数/去重项数 + 该
返回值取自回退路径可能失准"作为事实告警报出（每类一次）。
验证：冒烟复刻本现场（表含重名 'children' 且其类型为联合 i8*；body 10 槽）——逐字段
1..9 全部命中（parent=1 … children=7、type=8、name=9），无重名的自洽表行为不变；
FuncGen / StructGen 两文件 py_compile 通过。
|
2026-09-29 23:48:52 +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
|
b06dac1d6b
|
fix(LLVMCG): 字段偏移改用「冻结表有效性锚点 + 尾部对齐」，AnnAssign.value 不再读到 i32
类别：a 编译器缺陷（TPC 侧）
现象：编译 TranslatorGenMixin.vp 时 fail-fast —— getelementptr(GEP) 的指针操作数不是
指针类型：操作数类型=i32、操作数名='value.9'、GEP 名='vtable_slot_AST'。即
`aa.value.kind()`（TranslatorGenMixin.vp:788）的接收者读成了整数：AnnAssign.value 落到
槽 3（lineno, i32），随后虚分派取 vtable 时把 i32 当指针用。
根因（两条独立判据，均写进代码注释与告警报文）：
1) 冻结表陈旧：StructGen 建 body 时把「成员名→槽位」挂在 struct 实例上，而 body 之后会被
「不完整即清除」（StructGen 预检 existing_st.elements = None）与 stub 加载
（HandlesImports._TryLoadStructFromStub 的 set_body）清空后重设，重设路径不更新该表
⇒ 陈旧表按旧布局取槽（AnnAssign 在「自有 4 字段 + vtable」时冻结 {'value': 3}，body
被重设为 12 槽正确布局后仍取槽 3）。修：建表时同时记下 body 对象身份
（_tpc_member_body，set_body 每次赋新 tuple），查询侧用 `is` 判同一性，失效即不再采用。
2) 未展平成员表：表只含自有字段（父类前缀未补齐）时，「base(0/1) + 表内下标」会把整类字段
整体前移（target/annotation 落到指针槽 ⇒ 类型巧合、静默读错对象；value 落到 i32 槽 ⇒
本次崩溃）。修：表短于 body 字段区时按**尾部对齐**取槽（展平规则 = 父类前缀 + 自有字段
⇒ 自有字段恒为 body 尾部 len(表) 项），并用 _MemberSlotAccepts 逐项类型比对自校验；
表自洽（长度 == 字段区）时本路径不介入 ⇒ 对既有正确行为零变化；REnum 是 max-variant
镜像布局，明确排除。命中时每类留一次告警，报出表长/字段区/取槽结果。
验证：8 例冒烟（冻结表新鲜；陈旧×展平表 / ×自有表；无冻结×自有表 / ×展平表；无 vtable；
整类逐字段 = 8/9/10/11；尾部类型不符时落回旧路径）全部通过；两文件 py_compile 通过。
|
2026-09-29 23:18:37 +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
|
f28ff1b414
|
fix(tpc): 字段偏移改为「布局真源优先」，成员表漂移不再整体平移
类别 a（编译器缺陷）：_get_member_offset 返回 `base + 成员表下标`，但 class_members
是**可变**表（继承展平会在父类就绪后前置前缀、跨模块可按需重载/重跑），而 struct
body 一旦 set_body 即**永久冻结** ⇒ 表与布局的序位一旦漂移，整类字段偏移整体平移。
现场（IR 实证）：Converter 模块读 `Alias.name` 落在 struct 槽 9（= asname），而定义
模块 Alias.__init__ 写入槽 8；`import t` 无 as 子句 ⇒ asname=NULL ⇒ TransPyV StubGen
误报「import 别名 name 为空（_copy_str 返回 None）」并终止 includes/stdint.vp 的 vpi
生成。同族旧现场：ast.Constant.lineno 取到 pool 槽（已由成员偏移同源修复过）。
- StructGen._generate_structs：set_body 时把「成员名 → 槽位」映射冻结到 struct
实例上（_tpc_member_slots / _tpc_member_base）。用**实例属性**而非全局表：同一
类名可能存在不止一个 struct 实例，偏移必须与被 GEP 的那一份布局同源；仅当
member_types 恰为 `[vtable?] + 全部成员` 时记录（位域类折叠为单一 storage 槽，
其字段位置另由 class_member_bitoffsets 表达；stub 已置 body 的情形不记录）。
- FuncGen._get_member_offset：新增两条「只看布局」的路径，优先于原下标法——
① 冻结映射命中即返回；
② 用**类型**把成员表逐项配对到 elements（类型不匹配、重名的条目视为方法/占位/
漂移项，不占槽位），配对中类型相等的槽位即字段真实槽位。
表与布局自洽时两者给出与旧下标法逐字相同的结果；都覆盖不到才落回下标法（对既有
正确行为零变化）。另在「配对结果 ≠ 下标法」时每类每字段告警一次，报出成员表项数
与 struct 槽数，把漂移来源变成可见事实。
本地冒烟（三类，均通过）：自洽表 8 / 漂移表（类型不匹配）8（旧下标法 9）/
全同型漂移且命中冻结映射 8。
|
2026-09-29 19:57:57 +08:00 |
|
|
TermiNexus
|
d305d3369b
|
fix(tpc): IR 边界补「指针操作数类型守卫」，非指针值不再抛裸 AttributeError
类别 a（编译器缺陷／诊断缺失）：llvmlite 的 IRBuilder.gep 不做任何类型校验，
GEPInstr.__init__ 直接读 ptr.type.is_opaque；LoadInstr 同族亦同（instructions.py
:440/:558）。上游一旦把非指针值（典型 i32）当指针传入，抛出的就是裸
`AttributeError: 'IntType' object has no attribute 'is_opaque'` —— 报文里既没有
指令名、没有操作数、也没有当前语句，无法定位发射点（现场：Phase2 翻译
TransPyV/App/lib/core/Gen/TranslatorGenMixin.vp 时只带 713/787/788 三条语句位置）。
- BaseGen：新增 RequirePointerOperand（IR 边界先行判定，不做兜底转换）与
_GuardIrBuilder（无条件覆盖 gep/load/store，合法 IR 与原生 ir.IRBuilder 一致）；
_HotspotSiteBuilder 改继承 _GuardIrBuilder；_NewIrBuilder 未启用热点统计时
由原生 ir.IRBuilder 改为返回 _GuardIrBuilder。
- MemoryOps：_EmitLoad/_EmitStore 的 volatile 分支直接构造 LoadInstr/StoreInstr，
绕过了 builder.load/store 的类型守卫，补同一判定（非指针 ptr 的 store 会静默
生成非法 IR 文本）。
报文含：指令名、操作数类型、操作数名、GEP 的 name=（发射点标识）+ 当前节点位置。
|
2026-09-29 19:24:27 +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
|
aa1b536517
|
perf(tpc): _generate_structs 去掉两处"纯 no-op 重建"，不改任何判定语义
类别：b（机制漏缓存）—— 都是"结果等价却重算"的浪费，不是判定逻辑改动。
证据（PROF\main_prof_72472.prof 的 `_generate_structs` 子调用归属，self=39.07s/8,493 次）：
isinstance 6.195s（6,249 万次）· `HandlesBase.__get__` 3.596s · len 2.892s
`_TypedPointerType.__init__` 2.600s（375 万次）· `_patched_new` 2.030s · dict.get 2.555s
`_MemberSlotAccepts` 2.437s · SymbolTable.lookup 2.105s · rsplit 1.123s
改动（均为**恒等变换**，任意中断/交错下语义不变，不引入失效判定）：
1. Step 3 成员类型重绑：新增 `if pointee is not struct:` / `if member_type is not struct:`
短路。原实现对"pointee 本来就是该 struct 实例"的成员也**现建一个 ir.PointerType
再覆盖写**——llvmlite 类型是值语义（`_TypedPointerType.__eq__` 按 pointee 比较、
打印只取决于结构），覆盖写是纯 no-op。该分支每次调用遍历全部类的全部成员
⇒ 这是 375 万次指针构造（约占本函数 9s，含 _patched_new/_patched_init/_IsBadPointee）
的主源。
2. T* 占位扫描改为 `_StructBodyHasPlaceholderT`（按 body 对象记忆）：Step 4 的
"全类×全元素"扫描与 set_body 前的复核扫描，每次调用都全量重扫，是本函数
6,249 万次 isinstance 与 498 万次 rsplit 的主源。判据精确性：该扫描是
`st.elements` 的纯函数，而 `elements` 在 llvmlite 里**整体替换**（set_body 赋新
tuple、作废置 None，从不原地改元素）⇒ 用 `elements` 的对象身份当版本号即可精确
判定"body 未变"；缓存条目强引用 struct 与 elements，二者存活 ⇒ id 不会被回收
复用 ⇒ 不会误判命中。
3. vtable 槽 `i8*` 改用模块级共享实例 `_I8_PTR`（原来每类每次现建）。
**刻意不做**：不加"全量状态签名 early-out"。理由（写在此处备查）：签名只能覆盖
"每类成员个数"这类可 O(类数) 取得的量，覆盖不到"成员类型原地替换"；而那次替换正是
本函数 Step 3 自己做的 ⇒ 一旦某轮在中途抛异常，签名与上一次成功轮相同，early-out
会跳过**必要的**重建。要做到完备就得给约 25 处 `class_members` 变更点埋版本号，
收益不确定、风险实在，故不做。
验证：py 层 import + GetDiagnostics 干净；未跑编译器。
|
2026-09-29 16:37:03 +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
|
030d0fd149
|
feat(tpc): PROF 输出按编译启动时间分目录，不再清理旧目录
需求（2026-09-29）：PROF 按启动时间分组新建文件夹生成，不清理旧的 PROF。
改动：
- Phase2Translator：新增 `StartProfRun()`（在 PROF 根目录下按 `YYYYmmdd_HHMMSS`
新建本次编译专属子目录，同名补 `_N`；失败回落 PROF 根目录）与
`GetProfRunDir()`（主进程用已选定目录，worker 用继承的环境变量
`TPC_PROF_RUN_DIR` 复用同一目录）。原 `_CleanProfFiles()` 删除——它的语义
是"每次编译删掉 PROF 下全部 *.prof"，与"保留历次"直接冲突。
- worker_prof_*.prof 落 `PROF/<启动时间>/`。
- main_prof_{pid}.prof 与 main_time.txt 同样落该目录（Projectrans.py）。
- Config.main 启动时调用 StartProfRun 并打印本次输出目录。
子目录名经环境变量传子进程：ProcessPoolExecutor 用 spawn 起新解释器，进程内
模块态不共享，环境变量随进程继承 ⇒ 同一次编译的所有 worker 落在同一目录，
不会各建各的。
|
2026-09-29 16:26:44 +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
|
ac0d0f2cc8
|
perf(tpc): _MemberSlotAccepts 身份短路 + _generate_structs 热路径局部化（profile 第二梯队）
依据 PROF/main_prof_10152.prof（tottime 2288.9s / 72 文件顺序翻译）：
_generate_structs 自身 268.6s cum 1893.2s 15762 基本/35240 总调用
└ 子调用：_TryLoadStructFromStub 1589.5s×418k、_MemberSlotAccepts 61.1s×54.2M
isinstance 39.7s×300M、PointerType 构造 68.7s×15.9M、
SymbolTable.lookup 16.7s×15.9M、__len__ 6.8s×15.9M
本次两处（均等价改写）：
1. StructGen._MemberSlotAccepts：在 `Declared == Slot or str(Declared) == str(Slot)`
之前加**身份短路** `Declared is Slot`。该函数被 _generate_structs 调 54.2M 次，
其中 llvmlite `Type.__eq__` 合计 ~30s（types.py:178/303/550/720）+
`str()` ~3.3s；同一对象（body 与 class_members 引用同一类型对象）是其常见形态。
2. StructGen._generate_structs：把 `self.SymbolTable` / `.lookup` 提升为函数级局部
（真值语义逐字保持：SymbolTable 定义了 __len__，故先取 `bool(_symtab)`），
消掉逐类重复的属性查找与 15.9M 次 `__len__`。
说明：本提交只做等价微优化；本函数的大头（35,240 次全量 O(类数×成员数) 扫描、
429k 次结构体 stub 加载、1407 次泛型特化整类发射）需要结构性改动，另行评估。
|
2026-09-29 14:41:48 +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
|
25cda80995
|
fix(tpc): 补齐单/多参泛型类下标注解（list[str] → %"{模板sha1}.list[str]"*）
类别：a 编译器缺陷（机制缺失：两个注解解析器都只认双参定长 list[T, N]）。
现场（前序报错）：CallGenMixin.vp:149 调 ClassGenGeneric._specialize_generic_class
报「%\"650c1c3366d09e39.list[str]\"* 不能隐式转 i32」——实参侧正确、**形参侧
`type_args: list[str]*` 在符号表里成 i32**。同类：字段
`TypeGenBase.CTypedefNames: list[str] | t.CPtr` 在共享符号表里成 i8*（实测
temp/_shared_sym.json）。
真根因：单参泛型类下标在两处注解解析器里都无人处理，直接落到"未知类型"兜底：
· TypeAnnotationResolver._from_node_subscript（IsListAnnotation 只认双参）
→ `return CTypeInfo()`（空 ⇒ i32 / 与 t.CPtr 合并成 i8*）；
· LLVMTypeMapper._resolve_subscript → warn + 'i32'。
而声明端 DeclarationGenerator._get_type_str 的泛型分支（L1393-1423）**一直是对的**
（`%"<模板sha1>.<特化名>"*`），三处规则分裂。
修复（一条规则源 + 两处消费 + 一处物化）：
1. SymbolUtils 新增 ResolveGenericClassSpecName / IsGenericClassSubscriptBase ——
与 DeclarationGenerator 泛型分支逐字同口径：
spec = 基名 + '[' + ']['.join(ResolveGenericTypeArgStr(实参)) + ']'；
判据=该基名**有类定义**（符号表条目 IsStruct 或任一命名空间命中，实测 list
条目 IsStruct=True，故等价覆盖声明端 non_struct_types ∪ _generic_class_names）。
另加 GetStructSha1MapFromSymtab / GetTCAliasMapFromSymtab（从
SymbolTable.translator 取 Phase2 已挂好的 _struct_sha1_map /
_t_c_imported_names），供实参串跨模块类引用解析（'<sha1>.AST'）。
2. TypeAnnotationResolver._from_node_subscript 末尾（既有 rawptr/CPtr/CArray/
list[T,N]/tuple 分支**之后**）接入：产出
CTypeInfo(BaseType=CStruct(spec), IsStruct=True, Name=spec)（PtrCount 保持 0，
与本文件既有结构体 promotion 同口径：`X | t.CPtr` 取 max→1 层、
`rawptr[X]` +1→1 层，均与 declare 侧一致）。
3. LLVMTypeMapper._resolve_subscript 同样位置接入：产出 `%struct.<spec>*`
（与 _resolve_name / _resolve_attribute 的类引用同一表示）。
4. BaseGen._get_or_create_struct：特化名（含 '['）先按**基名**查
_struct_sha1_map 取模板 sha1 再拼 IR 名 —— 否则会用**使用方模块** sha1 拼出
'<本模块sha1>.list[str]'，与 declare/define 端 '<模板sha1>.list[str]' 分裂。
自测（vast AST）：list[str]→'list[str]'、dict[str,int]→'dict[str][int]'、
list[rawptr[AST]]→'list[AST*]'、rawptr[int]/tuple[…]→None（仍由既有分支处理）。
|
2026-09-29 13:17:36 +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
|
3bc3c48dee
|
fix(tpc): 注解解析补齐「有类定义 ⇒ 是类」——模块别名占裸名导致类引用退化成 i8**
类别：a 编译器缺陷（根因修复）。
现场：TransPyV Generator.vp:200 `self.ExprGenFstr = SubExprGenFstr` 报
「指针隐式转换已禁止（层数不同）：%\"a7b68c79f39cb4d3.ExprGenFstr\"* → i8**」，
成员槽来源明细显示：class_members[Generator] 下标 11 声明槽类型正确
（%\"a7b68c79f39cb4d3.ExprGenFstr\"*），但布局 struct
'47382dc8277c9d28.Generator' 的 elements[11]=i8**（set_body 只能设一次 →
错布局被永久冻结）。
已核对 temp/47382dc8277c9d28.stub.ll：declare 侧该槽逐字正确
（%"a7b68c79f39cb4d3.ExprGenFstr"*），Generator.vp 46 个字段全写作
`rawptr[X.X]`；.vpi 里注解文本也是 `rawptr[ExprGenFstr.ExprGenFstr]`。
真根因：`import lib.core.Gen.Expr.ExprGenFstr as ExprGenFstr` 的**模块别名**与
模块内 `class ExprGenFstr` 同名，平坦符号表（无前缀）一个名字只留一个条目 ⇒
TypeAnnotationResolver._from_node_attribute / _from_node_name 命中别名条目时
Copy 出「无基类型」的空 CTypeInfo ⇒ rawptr 下标分支按
`PtrCount = slice + rawptr(1)` 得 void 指针链（i8*/i8**），类身份尽失；
该值经成员提取（SymbolExtractor._collect_members → CTypeInfo.FromNode）
写进跨模块共享符号表，再由 FuncGen.setup_from_symbol_table 建出 struct body
→ 槽被冻结成 i8**。哪一字段中招取决于别名/类条目谁最后写入平坦表，
故三次构建分别命中 TypeGenCDef / ExprGenFstr（时变、非固定字段）。
修复：新增 TypeAnnotationResolver._RecoverTypeFromNamespaces —— 平坦条目
**不是类型**（模块别名/函数/变量/define/枚举成员占位）时，按 _namespaces
找回同名 typedef / 结构体（struct·renum·exception）/ 枚举条目，与
LLVMTypeMapper._resolve_name 既有「同名冲突找回类型」分支逐条同构（同一条
规则源）。挂接三处：_from_node_attribute 的条目分支与无条目分支、
_from_node_name 的条目分支。
口径细节：结构体表示与本文件既有 promotion 逐字一致
（BaseType=CStruct(name) + IsStruct + Name，**不加** PtrCount）——
rawptr[X] 的层数由 rawptr 分支自己 +1，此处再加会得 X**。
|
2026-09-29 12:44:03 +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
|
8263f6ec47
|
fix(tpc): 形参注解解析落到 i32 时 fail-fast（下标/联合形态不可能是 i32）
a 编译器缺陷（无兜底铁律）。根因链：stub 与 .vpi 两侧都写着
`type_args: list[str] | t.CPtr`（等价 `list[str]*`），**都对**；错在消费侧：
`LLVMTypeMapper._resolve_subscript` 对**单参泛型下标**（`list[str]`，非 `list[T, N]`
定长数组）没有分支，落到末尾 `回退到 i32` 的兜底 —— 该串经
SymbolTypeResolver → SymbolTable._InsertFuncSymbol 原样存进 `FuncPtrParams`，
再由 BuildLLVMFuncTypeFromSig 物化成**形参 i32**，于是调用点报
「实参 %"650c1c3366d09e39.list[str]"* 不能隐式转为整数参数 i32」，把真因
（注解没解析出来）掩盖成"调用点类型不匹配"。
改法：`get_func_param_type_str` 末尾加守卫 —— 注解是 Subscript / 联合（BinOp|）而
解析结果恰为 `'i32'` 时 fail-fast，并带上注解原文（由 SymbolTypeResolver 再补函数名/
形参序号与名字）。理由：下标形态的合法结果是容器/泛型/定长数组（指针、数组或结构体
指针），联合形态是 `T | t.CPtr` 的指针叠加 —— 都不会是 i32；只有"解析失败"才会是。
现场：CallGenMixin.vp:149 → `_specialize_generic_class(trans, gen_class_name, gen_type_args)`
callee=2292045c9694100e.ClassGenGeneric._specialize_generic_class
逐项 [3] arg=%"650c1c3366d09e39.list[str]"* param=i32
|
2026-09-29 12:09:12 +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
|
66de269ebf
|
fix(tpc): 撤回失效的"事后修复"，改为 set_body 前拦截降级布局（不冻结）
a 编译器缺陷。实测证据（07ea8e2f 的探针回执）：对本版本 llvmlite，
`st._elements = None` 之后 `st.set_body(*elems)` 仍以
`RuntimeError: <name> is already defined` 拒绝 —— 说明 **`_elements` 不是 set_body 的
判定存储**，即"清 _elements 以便重载/重设 body"这一全仓惯用手段在本版本是**空操作**
（结构体 body 一经设定即不可改）。因此：
- 撤回 7fb0e498 加的 `_SyncStructBodyTypes`（使用点就地修复）及其在
`_get_member_offset` 的调用 —— 它在本版本永不可能成功，只会把编译卡死；
- 改为**事前拦截**：`_generate_structs` 在 `set_body` 前调用
`_HasDegradedMemberTypes`，若本次布局里存在「注解是类引用（`Mod.Class` /
首字母大写裸名，排除 t/c 模块）**却**解析成 `i8**`」的成员，说明该 pass 类型尚未
就绪 ⇒ **不设 body、保持 opaque**，等类型就绪的 pass 再设。这样从根上避免
"降级布局被永久冻结"（现场：Generator 的槽 i8** 而声明 %"…ExprGenFstr"*，
赋值时报「层数不同」）。始终不就绪则在使用点响亮失败（opaqueness / 层数不同），
不再静默产出错布局。
- 新增 `_IsI8DoublePtr` / `_IsClassRefPtrAnnotation` 两个判据助手（保守：只在
"指针包装 + 类引用内层 + i8 系两层指针"三条同时成立时判降级）。
|
2026-09-29 11:56:08 +08:00 |
|
|
TermiNexus
|
07ea8e2fd9
|
fix(tpc): 布局校验/修复排除 REnum 镜像布局 + set_body 失败带回滚与上下文
a 编译器缺陷（承接 b8ed33a2 / 7fb0e498）：REnum 的 struct body 是 **max-variant
镜像布局** —— class_members 里的名字是*变体*而非字段，变体嵌套结构体也必须逐字
镜像主结构体。此前两处按"声明类型 vs 槽类型"的校验/修复会把这类布局当成错位：
- Step 4 前置校验可能据此清 _elements 重建；
- _SyncStructBodyTypes 可能据此改写布局（跨模块 GEP 偏移随即与定义端失配）。
新增 _IsRenumLayoutClass（主 REnum 自身 / `<REnum>_<Variant>`，判据走 SymbolTable 的
IsRenum）并在两处排除。
另外：就地修复的 `_elements = None` + `set_body` 一旦被 llvmlite 拒绝
（`<name> is already defined`，现场 fd4cd0ec583f42b9.Generator），原来会抛出这句
毫无上下文的裸 RuntimeError。现改为：捕获后**直接写回原 _elements 回滚**，再抛
FailFastError 带上类名 / struct / 原异常 / 元素数前后值，既不留中间状态也不再含糊。
|
2026-09-29 11:34:17 +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
|
7fb0e49854
|
fix(tpc): 成员偏移查询点就地修复错位 struct body（修正晚于冻结的时序）
a 编译器缺陷（承接 b8ed33a2）：Step 4 的前置校验只在**当次** _generate_structs 生效，
漏掉"class_members 被 .vpi/stub 修正在后、struct body 冻结在前"的时序 —— 于是
一次只修好一部分槽（实测：第 3 槽修好、第 11 槽仍错），错误逐个前移。
证据链（成员槽来源明细 + 全盘 grep）：
class_members[Generator] 项数=47 base=0 下标=11
声明槽类型=%"a7b68c79f39cb4d3.ExprGenFstr"*
布局 struct name='fd4cd0ec583f42b9.Generator' 元素数=47 elements[11]=i8**
且**没有任何** stub 文本里含 i8** ⇒ body 是从"当时已降级的 class_members"冻住的，
后来重载只修 class_members，改不了已冻结的 body（llvmlite set_body 只能设一次）。
修法：新增 StructGen._SyncStructBodyTypes —— 在**使用点**（_get_member_offset，
即任何 GEP 之前、成员表已在上方补齐/重载之后）按 class_members 逐槽比对，
只把**存储时必被拒绝**的槽（判据同 _MemberSlotAccepts）改回声明类型，其余元素
（含通用指针 i8* 槽）原样保留；_elements 置空后 set_body 重设（命名类型对象不变，
故已发出的 getelementptr %"name"* 不受影响）。同名类 sha1 冲突路径
（_ResolvedClass != ClassName）跳过，避免用别的同名类成员表写坏布局。
|
2026-09-29 00:19:06 +08:00 |
|
|
TermiNexus
|
b8ed33a200
|
fix(tpc): struct body 冻结前逐元素校验类型一致性（错位 body 不再被当"完整"）
a 编译器缺陷：_generate_structs Step 4 判定既有 struct body 是否"完整"时只比
「元素个数 / 首元素是 vtable 指针 / 是否含 T 占位」—— **类型错位**的 body
（个数命中、元素名也全对，但某槽被冻结成通用多层指针）会被直接 continue；
而 llvmlite 的 set_body 只能设一次 ⇒ 错布局被永久冻结，后续 .vpi / .stub 重载
只修 class_members、改不了 body ⇒ 赋值时报「层数不同」。
现场（成员槽来源明细实锤：声明侧正确、布局侧坏）：
class_members[Generator] 项数=47 base=0 下标=3
声明槽类型=%"d827f3045bd28467.TypeGenCDef"*
布局 struct name='fd4cd0ec583f42b9.Generator' 元素数=47 elements[3]=i8**
→ self.TypeGenCDef = SubTypeGenCDef
指针隐式转换已禁止（层数不同）：不能把 %…TypeGenCDef"* 隐式转为 i8**
修法：新增 _MemberSlotAccepts（判据与存储侧同一套 _ClassifyPtrImplicitConvert），
把 class_members 声明类型与 elements[base+i] 逐项比对；只有**存储时必被拒绝**的
组合（层数不同 / 指针与非指针混位）判为不一致 ⇒ 走既有「清 _elements + 清 stub
缓存」路径重建布局（通用指针槽 i8*、继承上转、数组退让照旧放行，不误清）。
|
2026-09-29 00:06:11 +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 |
|