GVSDS/ViperC
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
873 Commits 1 Branch 2 Tags
08fe5a7b6bb23498e744017ab15ccb689a79d3c7
Commit Graph
855 Commits
Author SHA1 Message Date
TermiNexus 08fe5a7b6b fix(viperc): 支持多级模块路径的 typedef 强转（win32.win32base.LPCWSTR） 2026-10-19 19:16:00 +08:00
TermiNexus 850f61dc22 refactor(viperc): 清理标记下标推导中的内联类型转换 2026-10-18 13:40:22 +08:00
TermiNexus 82a735c367 refactor(viperc): 完全删除 T1 | T2 类型组合，语法糖改用标记下标 2026-10-18 13:39:38 +08:00
TermiNexus 42b094a575 refactor(viperc): 退役 t/c 模块标记，内建类型改由编译器直接识别 2026-10-18 12:56:57 +08:00
TermiNexus 3242560d02 支持 tls 关键字，全面准备清退 t, c 2026-10-17 23:40:06 +08:00
TermiNexus 6e17716a69 revert(vtable): 恢复按类实际规模动态分配 
bf0bbcc 已经把固定上限去掉：收集前按「各父类 VTableMethodCount 之和 + 本类 FunctionDef 数 + 1」一次性分配三张表，越界检查保留为 InternalCompilerError。eff88dd 在并行开发中误把这段覆盖回固定 1024，这里恢复 bf0bbcc 的实现——无任意上限，且符合「能动态就动态」的既定规则。
 2026-10-17 19:22:50 +08:00
TermiNexus eff88dd591 fix(vtable): VTBL_METHOD_MAX 32 -> 1024 
memhub.MemBuddy 这类工具类的虚方法数远超 32，上一轮加的 fail-fast 直接把它拦下了。三张槽位表由 PermPool 分配（各 8*VTBL_METHOD_MAX），1024 时每类 24 KiB，可接受。
 2026-10-17 19:21:44 +08:00
TermiNexus bf0bbcc89b fix(vtable): 虚方法表按类实际规模动态分配，去掉 32 上限 
MemBuddy 继承 MemManager 后虚方法约 60+ 个，VTBL_METHOD_MAX=32 会触发 fail-fast（此前静默只收前 32 个，之后的调用点找不到槽位、退化成静态直调）。现在收集前先算容量上界：各父类已收集的 VTableMethodCount 之和 + 本类 FunctionDef 数量 + 1，三个 PermPool 数组按此一次性分配；两处越界检查保留为 InternalCompilerError（理论不可达）。删除 VTBL_METHOD_MAX。注：本次提交同时带上了该文件既有的 t.CPtr → rawptr 迁移与 _generate_default_init 删除等未提交改动。
 2026-10-17 19:20:03 +08:00
TermiNexus d46fdf152a refactor(struct): AST vtable 拷贝改为按 uint64 槽显式读写 
原写法 *dst_c = vt_ptr_c 把 i8* 赋给结构体类型的左值，TPC 会以「非基本类型禁止指针隐式转值类型」报错。新增 _copy_ast_vtable(src, dst)：把两侧 AST 节点都视作一个 uint64 槽（src_vt[0] -> dst_vt[0]），语义不变（只复制首字段 vptr），Constant 与 List 两条深拷贝路径统一调用它。
 2026-10-17 19:13:08 +08:00
TermiNexus 3e1e1fc1b3 fix(gen): 消除 ViperC 侧 P0 级静默截断 
match：case 数超过 MAX_MATCH_CASES 时 fail-fast（原先 break 会静默少分支，need_case 检查也发现不了）。vtable：初始化串按真实方法表动态分配，_vtable_strcat 溢出改 fatal；VTBL_METHOD_MAX 超限不再 break（原先子类 override 静默失效）。符号名：coro_pool_/__tls_init_done_/__decor_rec_/闭包 fn_ptr 的定义与引用改为按实际长度分配，消除 96 vs 128、64 vs 128 的不对称。Stub：_PyiEmit 溢出改 VLogger.error（半截 .vpi 会被当完整文件解析）；VpiReader 参数段/返回注解缓存槽放不下时 fail-fast，不再丢段导致形参注解错位。Includes：文件超过 1MiB 拒绝哈希（SHA1 冲突会让两个模块共用缓存）；add_file_entry 失败不再被忽略。f-string：格式串按字面量/转换符实际长度分配，字面量与 format_spec 溢出 fail-fast。
 2026-10-17 18:46:18 +08:00
TermiNexus 15952d3852 fix(asm): 内联汇编/LLVMIR 文本缓冲扩容并将所有超限改为 fail-fast 
ASM_TEXT_BUF_SIZE 2048→8192（内核 _do_switch 模板已 2245 字节），c.LLVMIR 模板 512→4096。_asm_append_cstr 不再静默截断：装不下时报 TypeError 并给出已用/待写/容量字节数（此前截断会把模板切成半条 mov，最终以 llc invalid operand 的面目出现）。操作数超过 16、clobber 超过 32、符号改写缓冲溢出同样 fail-fast；约束串/参数串/extractvalue 行缓冲改为按实际操作数与类型文本长度动态分配。
 2026-10-17 17:41:11 +08:00
TermiNexus 201c881b43 fix(assign): 拦截注解为类值类型但右值取地址的 typo 
dirp: devfs_directory = &directories[d]（注解漏写 *）此前会静默通过，把栈/表元素地址塞进值语义槽位，导致 vptr/父指针悬垂、对象被就地覆写。在 translate_annassign 中新增 fail-fast：注解解析为 struct（类值类型）而右值是取地址表达式（&x 或 c.Addr(x)）时报 TypeError 并提示补 *。新增 _is_addr_of_expr 助手，只认取地址，不含 *p 解引用，避免误伤值拷贝。
 2026-10-16 20:19:51 +08:00
TermiNexus 19feb40e8c fix(call): 实参个数与被调方不符时前端 fail-fast - 不再漏到 LLVM verifier(含 EH 参数扣除与可变参数放行) 2026-10-16 19:26:22 +08:00
TermiNexus 2f4031b3d6 chore(typegen): read_all 长度参数去掉多余 ULONG 转换 2026-10-16 16:40:41 +08:00
TermiNexus d8648176e9 feat(asm): op=/clobber= 支持裸枚举名(CLOBBER_MEMORY) - 等价 ASM_DESCR.XXX 2026-10-16 15:26:17 +08:00
TermiNexus e796314a24 fix(gi): 模块级空数组字面量 = [] 改走 zeroinitializer - 修大数组被逐元素展开(元素过多+池耗尽) 2026-10-16 13:02:38 +08:00
TermiNexus c57c931099 fix(cdefine): 支持浮点常量表达式(define X = 160.0 * 4) - 含浮点字面量时按浮点求值登记 double 2026-10-16 11:23:41 +08:00
TermiNexus 832b0a5706 chore(diag): [VAR-DIAG] 增加 alloca 地址打印 - 定位 pos/npos 共享存储(值语义被破坏) 2026-10-16 00:12:06 +08:00
TermiNexus 6196bdfe56 fix(gi): 模块级负浮点字面量按浮点初始化(不再送整型提取器) - 修 double = -100.0 报错 2026-10-16 00:03:21 +08:00
TermiNexus d06e665ebd fix(cdefine): stub 读取对负浮点字面量/浮点强转包裹剥壳后再注册 - 修 X: double = -100.0 走整型提取 fatal 2026-10-15 23:46:25 +08:00
TermiNexus 5460d78ff1 fix(gi): 模块级类全局按值本位存储(仅 __new__ 类用指针) - 修 CAM: V3 被包成 Ptr 致悬垂误报 2026-10-15 23:11:24 +08:00
TermiNexus 9d0a43d5e6 chore(diag): [GVAR-DIAG] 模块级全局类型决策(hasnew/hasvtable/isoop) - 定位 CAM 被包成 Ptr 2026-10-15 23:06:20 +08:00
TermiNexus 15a210bede chore(diag): 变量声明槽类型 [VAR-DIAG] - 定位 class 标注是否被解析成 ptr 2026-10-15 23:00:04 +08:00
TermiNexus 59c032f135 chore(diag): CTOR-DIAG 打印构造类型与目标类型的真实 LLVM 文本 - 定位 CAM 全局值本位 2026-10-15 22:53:23 +08:00
TermiNexus 23236c88ea fix(lifetime): 裸构造判值拷贝不再依赖类型打印比较 - 修 CAM = V3(...) 全局赋值误报 2026-10-15 22:26:17 +08:00
TermiNexus d1dd6de070 fix(lifetime): 目标为值类型即判 LIFE_VALUE(不再要求源非指针) - class 局部变量内部为指针槽，修 stars 误报 2026-10-15 21:59:39 +08:00
TermiNexus cbadc356f9 chore(diag): life 判定加全量诊断 [LIFE-DIAG]/[RT-DIAG] - 定位 return col 误判 2026-10-15 21:54:08 +08:00
TermiNexus 5dc483e256 fix(lifetime): 值类型变量按值拷贝判据改为双非指针(不再依赖类型打印比较)，堆/静态登记优先 2026-10-15 21:47:30 +08:00
TermiNexus 6b86f846ca fix(lifetime): 值类型局部变量在同型聚合目标位置按值拷贝(LIFE_VALUE) - 修 return col 被误判 stack address escapes 2026-10-15 21:40:30 +08:00
TermiNexus 217f5f021d fix(viperc): 解引用赋值补位拷贝（*a = *b 按位重解释，不做数值转换） 
现场（math.vp sin/cos）：
    u: uint64 = 0; xv: double = x
    *&u = *&xv        # 位拷贝，应为 movq %xmm0, %rax
    ef: uint64 = (u >> 52) & 0x7FF
生成：404084 cvttsd2si %xmm0, %rax ← 把 double 数值截断成 int64
代价：u 成了数值截断结果 ⇒ ef/neg 全错；x 为负时（-1.5 → u = -1）ef 命中 0x7FF
⇒ 直接 return x - x = NaN ⇒ sin/cos 负参全废。

VPC 的 `*p = v` 目标路径无条件 coerce_to_type(rhs, pointee)；TPC 侧早有该判据
（HandlesAssign.py:592 调 HandlesSpecialCall.EmitRawCopyLlvm，注释明确"位拷贝，绝不转换"），
VPC 漏了 ⇒ 本次按同口径补齐。

- RHS 为 UnaryOp(Deref)（`*p`）且两侧是**等宽标量**时：按**源自身类型** load（类型与槽的
  存储类型一致），再 bitcast 成目的类型存回 —— 不做任何数值转换；
- 不用"按目的类型重解释的 load"（`load i64, ptr %xv`）：文本层 T2「store→load 转发」按**名字**
  替换，会把 `store double %x, ptr %xv` 的 %x 顶进这条 i64 行，报
  `use of value '%x' expects different type than prior uses: 'i64' vs 'f64'`；
- 源操作数限定非调用形状，避免与前面 rhs_val 的求值重复；源不是指针 ⇒ fail-fast；
- 两侧位宽不等或含聚合 ⇒ 不做位拷贝，交回 coerce 路径（等价改动前行为，聚合位拷贝未支持）。
 2026-10-15 20:16:50 +08:00
TermiNexus 5ea0ce094e fix(viperc): 恢复一元负号字面量按目标类型直出 f32（位宽根因已修，路径不再有风险） 
背景：负号字面量（float(-10.0) / x: float = -3.5）此前回退过——当时 MLIR 渲染报
「f32 类型配 16 位文本」，原因是 mlirlite.ConstFloat 用 snprintf 打印位型时，
高位置位的 32 位值会被按符号扩展后的 64 位打印。该根因已在 includes/mlirlite 侧修死
（提交 8dbad70：十六进制位数只由 MlirTypeText(ty) 定，与 MLIR 渲染器同源，构造上一致），
故此路径恢复为「正确路径」：f32 目标下直接物化 f32 常量，去掉 f64 常量 + fptrunc 的绕行。

- ExprGenOps.translate_unaryop 增加 target_ty 形参：目标为 32 位浮点时折叠直接出 f32 常量；
- ExprGenMixin 把 target_ty 透传给 translate_unaryop。
 2026-10-15 19:43:15 +08:00
TermiNexus 3e52baa209 fix(viperc): 回退一元负号字面量的 f32 直出，保留正号字面量与 CDefine 的 f32 直出 
- 现场二分定位：float(-10.0) / -float(10.0) 走「按目标类型直出 f32 常量」后，
  MLIR 渲染阶段报 float 位模式位宽不匹配（VKernel 整个编不过）；同一份 gfx.vp
  只把负号字面量换成正号就渲染通过，故该路径回退为改动前行为（按操作数自身类型
  出常量，f64 常量 + 使用处 fptrunc）。
- 保留两条已验证有效的修复：
  1) 正号浮点字面量在 f32 目标下直接物化 f32 常量（translate_constant）；
  2) CDefine 记宽度种类（1=f64 / 2=f32），define PI: float = ... 的使用处直出 f32
     常量（含 -PI —— 折叠按操作数类型出常量，操作数已是 f32，故仍是 f32）。
- define 常量补 ': int' 注解：无注解 define 按值的最小可存宽度物化（1/2 -> i8），
  直接当实参传给 list[int].append(x: int) 会落成 i8 != i32 被 mlir-opt 拦下
  （自举编译 TypeGenCDef 时必现）。
 2026-10-15 19:25:49 +08:00
TermiNexus 508428bbc9 fix(viperc): 浮点常量按目标类型/声明宽度直接出 f32，不再先出 double 
- 浮点字面量在 f32 目标（float(1.5) / x: float = 1.5 / f32 形参）下直接物化 f32 常量，
  负号折叠（-c）同口径；去掉旧的「f64 常量 + fptrunc」
- CDefine 浮点条目记录宽度种类（1=f64 / 2=f32）：define PI: float = ... 的使用处
  直接出 f32 常量，与 f32 字面量混算不再被提升成 double（现场 33 处 cvtss2sd）
- 本模块注册 / pyi·vpi 跨模块重解析 / xmod 缓存三处都按注解裁决宽度，保持跨模块一致
 2026-10-15 18:35:48 +08:00
TermiNexus 3a687db0bb feat(viperc): 静态常量算式补上除法/整除/取模折叠（与运行期 sdiv/srem 同口径） 
此前纯常量折叠只覆盖 + - * | & ^ << >>，Div/FloorDiv/Mod 一律落到运行期 sdiv/udiv/srem/urem。现按同一维护口径补上：以精确值折叠，再由既有逻辑按结果值自动提升位宽（不无故抬宽，避免把 A/1 这类算式整体抬成 i64）。语义与运行期一致：Div/FloorDiv → sdiv（向零截断）、Mod → srem（余数符号随被除数）——宿主侧 // 与 % 正是这两个语义，无须额外修正；无符号位型常量按规范恒为非负，与运行期 udiv/urem 取值一致。除零不交给宿主（会打挂编译器）：先关掉折叠再 fail-fast，诊断文本与 AssignGenMixin 的常量求值器保持一致。
 2026-10-14 22:28:43 +08:00
TermiNexus 38a277a914 feat(viperc): 纯常量折叠补上 / // %，与 + - * 同口径（精确值 + 按值自动提升位宽） 
口径与 AssignGenMixin 的常量求值器逐字对齐：①除零先关折叠再 fail-fast（同一条诊断文案，避免交给宿主 Python 打挂编译器）；②结果按精确值自动提升位宽，不无故抬宽；③负数语义待定 ⇒ 本轮只折叠两侧都非负的情形（此时 sdiv 与 udiv 结果相同、无歧义），含负操作数的算式不折叠，照旧走运行期 sdiv/udiv/srem/urem。
 2026-10-14 22:27:55 +08:00
TermiNexus dc4468593c fix(viperc): CDefine 常量按位宽处理时不再把可容正值翻转成负数，修常量算式折错 
现场：Gargantua _start 的 string.memset(fb, 0, GW * GH * 4)（GW=160, GH=90）应折叠为 57600，实际生成 movl \（= -34560）作为 memset 长度 → 从 0x457ca0 写 4GB → 越界写撞到映射区末尾 0x467000，用户态 #PF err=0x7（cr2 与反汇编逐字对上）。根因：define GW = 160 的位宽按值推断为 8（无符号可容），而 _cdefine_bits_value/_normalize_cdefine_bits 无条件 '(value<<56)>>56' 重解释为有符号 → 160 变 -96（=-96*90*4=-34560）。现只在两种解释都装不下时才截断；位型不变（const_int 本就按位宽截断），仅不再翻转可容正值的语义。
 2026-10-14 22:20:52 +08:00
TermiNexus a143c2de0c fix(stubgen): 装饰器循环变量改名 ddi，避免与默认值处的注解声明 di 冲突 
同一个函数里 di 先被 for 循环绑定为 int(i32)，后面又用注解声明为 sizet(i64) 且右值是运行期 i64 值：存储类型 i32 收不下，编译器按 fail-fast 报'带注解重声明冲突'（此前 TPC 是静默丢掉 store，生成的 viperc.exe 在 list[AST*].get 越界读）。装饰器循环改用 ddi，di 保持为首次声明。
 2026-10-14 21:13:03 +08:00
TermiNexus 7da9d7cb0d fix(viperc): 位宽探测循环改为固定 64 次上界，修主编译器死循环 
- 现象：Phase1 编译到 viperlib.vp 时卡死，栈顶停在 ExprGenOps.vp:1362（我新加的位宽探测 while）

- 原因：`while t != 0 { t = t >> 1 }`（t 为 int64）在生成代码里不收敛（疑似 i64 移位/比较被按窄宽度处理）→ 死循环；改为 `while i < 64 and t > 0` 的固定上界写法，两处（ExprGenOps 运行期常量折叠 / AssignGenMixin 静态求值）一起改

- 遗留待查：该 while 为何不收敛（i64 >> / != 0 的代码生成），属同类“最小宽度”问题面
 2026-10-14 19:54:29 +08:00
TermiNexus d09b79995d fix(viperc): 运行期纯常量整型算式按精确值折叠并按值定宽，禁止最小宽度回绕 
- 现场：`1024 * 1024 * 4` 在表达式侧按最小宽度(i16)运算，1024×1024 先回绕成 0 ⇒ 常量变 0（WINBUF_MAX_BYTES=0 ⇒ 窗口缓冲只剩几字节 ⇒ 内核 memcpy 240KB 越界读 → 三重故障）

- 在 translate_binop 取到操作数类型后加入纯常量折叠：+ - * | & ^ << >> 两侧都是编译期整型常量时按精确值求结果，并按“能精确容纳该值的最小合法宽度（下限取操作数较宽者）”定宽、向上取 8/16/32/64；只有装不下才加宽（与 61f23d9 的静态求值器同口径）

- 与 61f23d9 合起来：静态 define 求值与运行期常量算式都不再按最小宽度回绕
 2026-10-14 19:39:11 +08:00
TermiNexus 61f23d99a1 fix(viperc): 静态常量求值对 + - * << 按结果值加宽，杜绝 define 算式静默回绕 
- 现象：Gargantua 的 define V3_POOL_SIZE=8192 / V3_POOL_BYTES=V3_POOL_SIZE*24+512 在运行时变成 512（正好是表达式里的 +512），等价于 8192*24=196608 被按 16 位回绕成 0 → 池只剩 512B → 每像素 trace 立刻 OOM 刷屏

- 根因：extract_cdefine_int_value_bits 的 BinOp 位宽规则只“取较宽”，而 + - * << 会增长结果位宽 → define 物化时按 16 位截断

- 现在：操作数的声明宽度仍保持最小（不提升）；基准取较宽者；若精确结果装不进基准宽度，则按结果值加宽（向上取 8/16/32/64）—— 静态计算不再回绕；基准未知（纯字面量算式）时保持“未知”，仍由物化端按值推断

- 顺带：未知 BinOp 算子恢复 fail-fast（重构后原落空分支若留着会静默返回 0）
 2026-10-14 19:18:52 +08:00
TermiNexus 813b59e25f fix(viperc): 修正 (expr).method() 接收者误入 get_attribute_ptr 导致的 strcmp(_,0x1) 崩溃 
- 表达式接收者分支（L1236 设计上可收 BinOp/Subscript/Call）在接收者求值非指针时会调 get_attribute_ptr；该 API 只接受 Attribute，内部直接强转成 ast.Attribute 并读 .attr，对别的节点会命中偏移 9 的字段：BinOp 的 op（OpKind.Sub=1）、Name 的 ctx（ASTCtx.Store=1）等，于是把整数 1 当字符串传给 strcmp → ASan access-violation on 0x1

- 现在仅当接收者确为 ast.Attribute 时才走“取字段地址”，其余节点保持已翻译的接收者值（与旧实现的回退结果一致）

- 现场：Test/OopInheritTest/App/main.vp 的 (a3 * 2.0 - a4).cross(a5)，接收者 BinOp 的 op=Sub=1
 2026-10-14 17:57:01 +08:00
TermiNexus ee3337f3c4 revert(viperc): 回退闭包变量取址的放行，仅保留“实参级报错定位” 
- 回退 a060e1d 中 ExprGenOps 的闭包取址改动与 TypeGenErr 的临时打印移除：&_on_submit 仍按级数不符报 CastError（source level 2 -> target level 1），语义不变、不放行

- 保留 CallGenCall._call_method_on_ptr 的实参级 AST 节点透传：方法/构造实参转换失败时报错定位到具体实参表达式，并显示完整两帧（函数定义帧 + 错误点）
 2026-10-14 17:40:53 +08:00
TermiNexus a060e1d76e fix(viperc): 闭包变量取址返回闭包指针，并让方法/构造实参转换报错定位到具体实参 
- ExprGenOps 取址：嵌套 def 提升出的闭包变量在父函数里是 i8** 槽，&f 原来返回槽地址（二级），传给 callback: t.CPtr 会因级数不符报 CastError（source level 2 -> target level 1）；现按闭包名表判定，返回其值 i8*（一级），与“函数名即地址（同 C）”一致

- CallGenCall._call_method_on_ptr：实参逐个转换原来统一传 node=None，失败时只能退回函数定义行（只剩一帧）；现按 arg_nodes 带上每个实参自身的 AST 节点（slot 0 是 self），报错可定位到具体实参表达式并显示完整两帧

- TypeGenErr：移除定位用的 [TEMP-DIAG] 临时打印
 2026-10-14 17:38:50 +08:00
TermiNexus 3c6041c97c fix(viperc/diag): 把“当前实参位置”的记录点下沉到 translate_call_arg（覆盖所有调用路径） 
TEMP-DIAG 实测：node=0 curarg=0 trace=1 top=11 —— 节点是合成的（无行号），但“当前实参
位置”压根没被记录，说明该构造器调用没走 CallGenLib 的参数循环，兜底只能退回栈帧（函数定义行）。

改为在**所有调用实参的公共入口** CallGenBase.translate_call_arg 顶部记录（它持有 arg_node），
并移除 CallGenLib 里的重复挂点。这样任何调用路径（含构造器）都能把报错定位到具体实参表达式。
 2026-10-14 17:13:38 +08:00
TermiNexus ca81c1185c diag(viperc): 放宽报错位置兜底判据 + 临时打印定位决策输入（定位后删除） 
兜底判据改为：只要实参位置有效，且节点行号“不深于”栈最内层帧行号（或栈为空），就用实参
位置 —— 覆盖 FunctionDef 节点被传下来的情形（其行号恰好等于函数定义行、并非真实表达式）。
另加一行 [TEMP-DIAG]（node/curarg/trace/top/shown），用于一次看清兜底为何未触发；
定位完成后立即删除该行。
 2026-10-14 17:08:59 +08:00
TermiNexus 40ea5d6513 fix(viperc/diag): 节点行号等于函数定义行时也用实参位置兜底（定位到具体表达式） 
上一版只在 lineno==0 时用 CurArg 兜底；实测该报错的节点自带行号且恰好等于当前函数定义行
（节点其实是 FunctionDef 本身，构造器内联路径把它传了下来），于是兜底没触发，错误位置与
栈帧都在定义行、被去重合并，看起来只剩一帧。

现把“节点位置不可信”判据放宽为：lineno==0，**或** lineno 等于最内层栈帧的行号（即函数
定义行）→ 两条都优先用 CurArg，报错精确指向调用处的实参表达式（如 `&_on_submit`）。
 2026-10-14 17:02:16 +08:00
TermiNexus 4f45b391ea fix(viperc/diag): 保留函数定义帧，不覆盖栈帧位置（补齐“定义帧 + 出错语句帧”两帧） 
上一版 B 把最内层栈帧的位置改写成“当前语句”，结果它与错误帧落在同一 file:line，
被去重合并 —— 输出只剩一帧，`_start` 那帧（函数定义）反而没了。

改为：栈帧只记录**被调函数的定义位置**（不随语句推进覆盖）；“当前语句/具体表达式”
统一由错误帧给出（CurArg 兜底，见 TypeGenErr）。这样能得到完整两帧：
  File "./Apps/HelloWorld/main.vp", line 11   export def _start() -> int:   ← 定义帧
  File "./Apps/HelloWorld/main.vp", line 36   ... &_on_submit)             ← 出错语句帧
同时删除已无调用的 TypeGenBase.update_top_trace_position。
 2026-10-14 16:51:51 +08:00
TermiNexus d6b87da063 fix(viperc/attr): 不再要求 import c 才认 @__attribute__（否则函数属性被静默丢弃） 
ast/parser.vp 的 _DesugarMagicAttribute 会把用户写的 `@__attribute__(...)` 脱糖成
`@c.Attribute(...)`，此处看到的 `c.` 前缀是编译器自己产生的（用户并未写 `@c.Attribute`）。
原先这里要求 is_module_imported(...,"c")，用户没写 `import c` 时整条装饰器被静默丢弃，
stackrealign / always_inline 等函数属性全部失效。现去掉该守卫，与 extract_func_section
（本就没有此守卫）保持一致。
 2026-10-14 16:42:16 +08:00
TermiNexus 0f2675e794 fix(viperc/codegen): Win64 变参提升按实参符号性选择 zext/sext，避免无符号值高位被填脏 
变参调用把 <64 位整数提升到 i64 时原先一律 sext：uint8 0x8E 会被填成
0xFFFFFFFFFFFFFF8E，va_arg(i64) 读到脏高位（即 Debugger/VKERNELERR.md 记录的 sext 家族）。
现按实参符号性选择：无符号走 zext、有符号仍走 sext，与
CallGenVa._check_and_promote_variadic_call 同口径（复用 ExprGenOps.should_zext_widen）。
 2026-10-14 16:41:58 +08:00
TermiNexus 0678cc8c48 feat(viperc/diag): 报错定位到具体表达式 + 栈帧跟踪当前语句（方案 A+B） 
A：报错节点是合成节点（lineno==0，如构造器内联出的参数赋值）时，优先用“正在翻译的实参
   位置”兜底 → 报错精确指向调用处的表达式（如 `&_on_submit`），不再退回函数定义行。
   - TypeGenBase 新增 CurArgFile/CurArgLine/CurArgCol 与 set_cur_arg()
   - CallGenLib 翻译实参前调用 set_cur_arg(当前文件, arg_node 位置)
   - TypeGenErr 兜底顺序改为：节点自身行号 → CurArg → 栈最内层帧
   - 语句边界清空 CurArg，避免兜底串味到上一条语句的实参

B：栈帧跟踪“当前语句”位置（Python traceback 口径）
   - TypeGenBase.update_top_trace_position()：更新最内层帧的 lineno/col
   - translate_stmt 每条语句推进时调用 → 报错时栈帧给出的是调用点所在语句，而非函数定义行
   配合 A 即可得到“调用点 + 具体表达式”两帧。
 2026-10-14 16:40:35 +08:00