TermiNexus
d3537c7b3f
【类别 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(-)
TransPyC
TransPyC 是一种基于 Python 语法的系统级编程语言编译器，将 Python 子集（通过 t/c 模块类型注解赋予 LLVM 语义）编译为原生机器码。它不是 Python 的子集，也不是 C 的语法糖——它拥有独立的类型系统、两阶段编译模型和 SHA1 命名空间机制，适用于操作系统内核、嵌入式系统、驱动程序等底层开发场景。
能力证明
TransPyC 已用自身实现以下组件，证明其作为系统级语言的成熟度：
- ViperOS —— 真实操作系统内核（ViperOS/），含 gdt/idt/isr/mm/sched，可在 QEMU 启动
- 自研 Python 解析器 —— includes/ast/（4,176 LOC），用 TransPyC 自己写的词法+语法+AST，覆盖 CPython 几乎全部语法
- 自研 LLVM IR 生成库 —— includes/llvmlite/（~1,500 LOC），用 TransPyC 自己写的 IR 文本生成器，18/18 测试通过
- zlib 移植 —— Test/ZlibTest/，完整 deflate/inflate/huffman/checksum（~1,900 LOC）
- Win32 FFI 绑定 —— includes/w32/，file/memory/process/sync/console 全覆盖
- 泛型容器 —— includes/linkedlist.vp，
@t.NoVTable+ PEP 695 递归泛型继承class GNode(GSListNode[GNode])
核心设计理念
- Python 语法，LLVM 语义：源文件是合法的 Python 语法，但通过
t模块类型注解赋予 LLVM 级别的语义 - 类型注解即编译指令：类型注解决定 LLVM IR 的生成，不是可选的提示
- 两阶段编译：先提取声明接口（
.vpi+.stub.ll），再翻译源文件为含代码的.ll - SHA1 命名空间：每个源文件按内容 SHA1 哈希命名，自动消除跨模块符号冲突
- 零运行时开销：编译为原生代码，无 GC、无解释器、无虚拟机
自举进展
TransPyC 正在追求完全自举——用 TransPyC 重写 TransPyC 编译器自身。当前状态：
- ✅ 前端：
includes/ast/已替代 Pythonast模块依赖 - ✅ 后端：
includes/llvmlite/已替代 Pythonllvmlite依赖 - ⏳ 中间层：
lib/core（~20K LOC）待用 TransPyC 重写
模块总览
Viper 语言通过两个核心模块提供类型和操作支持：
| 模块 | 用途 | 导入方式 |
|---|---|---|
t |
类型定义系统 | import t |
c |
C 语言操作指令 | import c |
快速上手
- 环境：Python 3.12+、LLVM（llc/clang）、Windows（当前主平台）
- 构建项目：在项目目录运行
python ../Projectrans.py build（详见 wiki/12-project.md） - 示例：参考 Test/ 下 30+ 测试项目（AstTest/ZlibTest/NoVTableTest/LLvmLiteTest 等）
- 写第一个程序：
import t, c
from stdint import *
import stdio
def main() -> CInt | CExport:
stdio.printf("Hello, Viper!\n")
return 0
文档索引
| 文件 | 内容 |
|---|---|
| 01-overview.md | 语言概述、两阶段编译流程、SHA1 命名空间、t.CDefine/t.CExport/t.CInline 深度解析 |
| 02-type-system.md | 类型系统（基本类型、指针、数组、结构体、联合体、枚举、typedef、__attribute__） |
| 03-variables.md | 变量声明与赋值（含 t.CDefine 常量） |
| 04-functions.md | 函数定义与调用（含 t.CExport、t.CInline、t.CDefine 函数、-> tuple[...] 多返回值） |
| 05-classes.md | 类与数据布局（结构体、联合体、枚举、typedef、位域） |
| 06-oop.md | 面向对象与运算符重载（@t.Object、@t.CVTable、@t.NoVTable、继承、dunder 方法） |
| 07-control-flow.md | 控制流（条件、循环、match） |
| 08-c-operations.md | C 语言操作（指针、内联汇编、FFI 外部函数声明、LLVM IR 内联） |
| 09-exceptions.md | 异常处理 |
| 10-imports.md | 模块与导入系统（存根生成、SHA1 命名空间与导入） |
| 11-builtins.md | 内置函数与运算符 |
| 12-project.md | 项目配置与构建（增量编译、SHA1 映射） |
| 13-bootstrapping.md | 自举可行性分析（当前进展、剩余工作、路径规划） |