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
|
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
|
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
|
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
|
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
|
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 |
|
TermiNexus
|
c83fc752c6
|
fix(sizeof,parse): 尺寸链去静默兜底,解析报错可定位,补 C 解析器缺口
StructGen: _get_struct_size/_get_align 去 opaque→8/ptr_size、未知→4 兜底并补 VectorType;LiteralStructType.fields→.elements(llvmlite 无 fields,必然 AttributeError)
HandlesClassDef: union 载荷尺寸经不存在的 ir.DataLayout 静默退化成 8 字节;HandlesExprCall/ExprBuiltin: sizeof 各静默 0 分支改 fail-fast,数组元素 sizeof 统一走 _get_struct_size
HandlesFor: nonlocal struct/array 堆分配不再退化成 malloc(8)
vast/vast_c: 补一元 * / & 解析,装饰器后 extern/export 分派修复,C 侧报错带 token 与行号;StubGen.Converter: 宏展开丢尾随空行修 .pyi 缩进非法
其余为 rawptr 迁移 / fail-fast 口径等历史改动一并入库
|
2026-09-26 19:27:22 +08:00 |
|
TermiNexus
|
2cc816ac13
|
修复了一些错误
|
2026-09-18 20:00:59 +08:00 |
|
TermiNexus
|
6af2dea917
|
修复了一些问题
|
2026-09-17 14:52:37 +08:00 |
|
TermiNexus
|
43e7cdd2cc
|
feat(tpc): 函数级 DWARF 调试元数据 + 合并 IR 元数据规整
DWARF: 新增 LLVMCG/DebugInfo.py(DebugInfoEmitter)——每模块一个 DIFile/DICompileUnit、每个 define 一个 DISubprogram 并在函数入口首条指令挂 DILocation,模块落盘前补 !llvm.dbg.cu 与 !llvm.module.flags(Debug Info Version 3)。开关:新增 --dwarf(默认关闭),dwarf_enabled = args.dwarf or args.asan,沿 Phase2Translator → _translate_file → Translator.DwarfEnabled → LlvmCodeGenerator.dwarf_enabled 下传。define 之外的 declare 不挂。include 库刻意不给 DI(其 .obj 进跨项目共享的 includes.binary 缓存,注入会污染缓存)
关键约束(踩过的坑,已在探针中实测):DICompileUnit 与 DISubprogram 必须 is_distinct=True;emissionKind 用 FullDebug 而非 Full;spFlags 用 DISPFlagDefinition;DISubprogram 必带 type=DISubroutineType,缺了 llc 会崩 0xC0000005;模块级必须有 !llvm.dbg.cu + Debug Info Version 3
IRMetadataFix: 新增 SanitizeIRMetadata,在 _llc_compile 入口统一规整 IR——BuildCombinedIR 是多模块 IR 文本直接拼接,--dwarf 后每个片段自带 !0..!N 与两份命名元数据,22383 行样本里 !0/!1 各重复 67 次导致 opt/llc 报 Metadata id is already used。实现:按块重编号 !N 并改写 !dbg/命名元数据引用、!llvm.dbg.cu 全量聚合、其它命名元数据全同去重;无元数据文件逐字节 no-op、幂等(1.7MB/0.30s)
顺带修 _AddWeakComdat:函数头正则跨行吞换行,--dwarf 把 !dbg 放到 define 行尾后 comdat 被插到 ! 附着之后,llc 报 expected { in function body(现场 52 个 define 中 36 个中招);改为插在附着之前,无 !dbg 时产物逐字节不变
已自证:llc/opt RC=0、行表含 .vp 文件名与行号、opt -passes=forceattrs,asan 与 llvm-link/always-inline 均不丢 !dbg。已知待办:llc 现报 inlinable function call ... must have a !dbg location ⇒ 需补语句/调用点级 !dbg(否则警告 ignoring invalid debug info 会丢弃整份 DI)
|
2026-09-16 19:29:51 +08:00 |
|
TermiNexus
|
2021c0edb7
|
feat(hotspot): 新增 --hotspot-sites 逐调用点计数并带源码 file:line
为匹配白名单的直接 call 点插桩 internal i64 __fhs_site_<K>(call 前 +1),计数天然包含循环内放大的真实执行次数,可把热点定位到具体调用点。
新增 --hotspot-callees 覆盖白名单、--hotspot-sites-all 全量;按去 16 位 sha1 前缀后的基名匹配。Ctrl+C 落盘独立文件 hotspot_sites.txt(# sites 分段,含调用方/被调方/计数/源码位置),按计数降序;不破坏既有 hotspot.txt 格式。
在 AST->IR 生成期由 _HotspotSiteBuilder 为每条新生成的 call 指令轻量挂载 _src_file/_src_line,插桩时作为可选尾字段输出;取不到则留空不伪造。开关关闭时改用原生 ir.IRBuilder,零影响。
|
2026-09-13 23:29:32 +08:00 |
|
TermiNexus
|
0bda395ecc
|
fix(translator,peephole): TPC 属性链解析修复与窥孔 T1-T3 收尾
- TPC(lib/core): 泛型父特化形参按声明类登记 var_struct_class; _find_struct_key 键归一支持方括号内嵌 sha 前缀; 字段探测失败不再冒泡 FuncGen fail-fast; cast 局部通用指针槽按静态类 bitcast; 属性解析失败附诊断
- 窥孔(includes/llvmlite/__function.vp): 窥孔移至 Renumber 前使输出 SSA 编号连续; T3 no-op bitcast 消除; T4(数组 bitcast->GEP)验证干扰返回类型收敛已移除
- 附调试打点与 1.log
|
2026-09-08 12:52:48 +08:00 |
|
TermiNexus
|
45e78ad107
|
基线重置,修复了一些 bug
|
2026-09-07 14:46:02 +08:00 |
|
TermiNexus
|
50ca560563
|
fix(tpc): list 联合类型方法分派保护 + str 压平条件收紧 + external global 裸名兼容
- HandlesAssign: 变量已有同 base 声明类型时不再覆盖 var_struct_class(sha1 前缀特化名覆盖裸名,导致 dbody.get 查表 miss 后 fallback 到 list[int].get,i32 返回值被截断成垃圾指针崩溃——TPC 侧根治)
- HandlesExprCall: IdentifiedStructType 真值判断改 is None(opaque 时 bool() 触发 __len__ assert)
- HandlesFunctions/HandlesImports: IsStr 压平条件加 PtrCount<=1,str|t.CPtr(i8**) 不压平;external global 正则兼容裸名格式
|
2026-08-24 23:31:08 +08:00 |
|
TermiNexus
|
daf79af1cc
|
fix(tpc): 返回 fail-fast 豁免 void 联合注解与 extern/export 声明型函数
- sprintf 误报:返回注解 t.CVoid | t.CExport(BinOp BitOr 联合)被旧判定忽略 -> 掉出末尾误报,且 [FATAL] 终止杀死 include worker -> BrokenProcessPool
- 修复:新增 _IsVoidOrDeclAnnotation 递归识别联合注解(注解中 | 表示 and):void(None/t.CVoid)+ extern/export 声明型辅助符号(State/CExport/CExtern)均豁免
- 验证:t.CVoid|t.CExport / int|t.State / t.CVoid / None -> 豁免;裸 int -> 仍 fail-fast(missing_return 用例保持命中)
|
2026-08-22 05:17:03 +08:00 |
|
TermiNexus
|
4b0482657b
|
fix(tpc): 返回 fail-fast 判据改为源码层面——显式 return 结尾不再误报
- PopulateSha1MapStore 源码末句是 return(vast 解析 body[-1]=Return),但翻译后未 terminated(HandlesReturn L133 HandleExprLlvm 返回 None 时静默跳过 ret)被误判为掉出末尾
- 判据从 builder 状态改为源码结构:末句是 Return 或控制流(If/Match/While/For/Try/With)即不报错;只有末句是普通语句且非 void 注解才 fail-fast
- 静态检查(源码)与动态状态(builder block)分离,翻译层问题不该归类为源码掉出缺陷
- NegativeTest missing_return(末句 Assign)仍报错
|
2026-08-22 04:13:43 +08:00 |
|
TermiNexus
|
09d03f4525
|
fix(tpc): 返回 fail-fast 误报修复——末句控制流掉出末尾不报错
- 检查未区分普通语句掉出与末句控制流(match/if)掉出:match 翻译后停在合成 after 块(未 terminated)是机械产物,所有 arm 已 terminated 属正常(fatal_error + return None 样板),被误判为掉出缺陷
- 修复:Node.body[-1] 是 If/Match/While/For/Try/With 时豁免 fail-fast(符合隐式返回规则:末句控制流 -> unreachable)
- NegativeTest missing_return(末句 Assign)仍报错
|
2026-08-22 04:08:43 +08:00 |
|
TermiNexus
|
0ce4a4d073
|
fix(tpc): import 路径/隐式转换/缺失 return 三项漏检 fail-fast
- HandlesImports: 模块在所有来源找不到时 raise ImportError(原静默容忍导致跨模块 mangled fallback,链接期才暴露 undefined symbol)
- LlvmGenerator: import 处理 ImportError 直接重抛,不被 _ErrorStack 吞掉
- FuncGen: 指针→整数、浮点→整数隐式转换改 raise TypeError(显式 cast 仍允许,符合隐式转换规则)
- HandlesFunctions: 有非 void 返回注解但函数体掉出末尾 raise Exception(-> None / -> t.CVoid 视为 Void 仍合法)
- 新增 Test/NegativeTest 反向测试专项:9 个漏检用例,当前 9 PASS / 0 FAIL
|
2026-08-22 03:57:19 +08:00 |
|
TermiNexus
|
6fc9e19e24
|
feat(vast): 新增自研 Viper/Python 语法解析器取代标准库 ast
TPC 侧取缔对 Python 标准库 ast 模块的依赖,改用 lib/vast 包:
- Nodes: 与 CPython 3.12 ast 完全同构的 131 个节点类(含抽象基类继承)
- Tokenizer: 词法分析(缩进/字符串/f-string/数字/运算符/软关键字)
- ExprParser: 表达式递归下降解析(优先级/lambda/推导式/f-string/切片)
- Parser: 语句解析(def/class/if/for/try/with/match/import/注解)
- Utils/Unparser: walk/dump/unparse/copy_location/literal_eval 等辅助
- 软关键字 fn/fun/func/function 并入解析器, 废除 ExpandSoftKeywords 预处理
- lib/_bootstrap 将 lib 目录加入 sys.path, import vast as ast 零修改替换
- 52 个文件 import ast 替换为 import vast as ast; 94 文件差分测试 0 失败
|
2026-08-17 09:36:38 +08:00 |
|
TermiNexus
|
8ccf5d2c18
|
fix(TPC/includes): 泛型特化 linkonce_odr + None 全局 common + includes 前缀
- TPC HandlesFunctions/HandlesClassDef: 泛型特化类方法(类名含 '[')设
linkonce_odr,消除 GSList[NameEntry].__before_init__ 等 duplicate symbol
- TPC HandlesAssign: None 初值模块级全局用 common linkage,合并 _g_gen 等
跨模块同名全局重复定义
- includes: binascii/hashlib 裸调用加 stdlib./string. 前缀(malloc/free/memset/memcpy)
- llvmlite: FunctionPrint 泛型特化方法输出 define linkonce_odr;__module 调整
- 删除 wiki/01-overview.md
|
2026-08-12 18:18:22 +08:00 |
|
TermiNexus
|
a39b5da0f8
|
基本稳定
|
2026-08-05 20:11:38 +08:00 |
|
TermiNexus
|
ca7c2120b8
|
修正了种子编译器的错误
|
2026-07-22 21:55:36 +08:00 |
|
TermiNexus
|
a277ded8d4
|
修正了 TPC 的一些错误,包括 Test 维护后 TPV 无法重新编译或重编译后越界的部分问题
|
2026-07-20 11:12:30 +08:00 |
|
TermiNexus
|
4e66207ba1
|
重置上传,新增了多个标准库,开始 TransPyV 自举实验
|
2026-07-19 11:38:15 +08:00 |
|
t
|
796222a300
|
snapshot before regression test
|
2026-07-18 19:25:40 +08:00 |
|