TransPyC

0 Fork 0

Files

T

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

constants

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

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

core

fix(FuncGen): 成员表与 body 等长时不再做类型对齐校准（base 恒为 0），修 TypeGenMixin 字段偏移平移

2026-09-30 11:15:58 +08:00

includes

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

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

Projectrans

fix(HandlesClassDef/DeclarationGenerator): 未声明字段不再静默兜底 i32，推不出类型即 fail-fast