2026-03-25 Qlang 预研设计稿

背景

当前仓库是一个空目录，需要在真正开始写编译器之前，先把语言定位、关键技术假设、工具链范围和项目结构收敛成可执行方案。

核心决策

决策 1：语言定位

Qlang 定位为一门 LLVM-based compiled language，面向系统软件、基础设施、服务端和需要长期维护的大型工程。

决策 2：核心设计哲学

采用“对开发者简单，对编译器复杂”的方向：

• 默认不可空
• 默认不可变
• 默认值语义
• Result / Option
• 模式匹配
• trait 约束
• 推断优先的所有权模型

决策 3：实现语言

工具链推荐使用 Rust 实现，使用 Cargo workspace 组织编译器与工具链模块。

决策 4：互操作路线

• C ABI 为底座
• Rust 先经稳定 C ABI 混编
• C++ 第一阶段通过 shim
• 深层直接 C++ 能力延后到 P2

决策 5：仓库演进机制

采用 docs/ + spec/ + rfcs/ + crates/ + stdlib/ + tests/ 的分层结构。未来所有重大语言变化走 RFC。

关键收益

对开发者

• 代码表面更接近主流静态语言
• 安全规则统一且可解释
• FFI 与工具链前置设计，减少“语言能跑，工程不能用”的风险

对实现

• 编译器、LSP、格式化器和文档生成可建立共享语义数据库
• AST/HIR/MIR 分层使重构和优化更可控
• P0/P1/P2 边界清晰，避免路线图失焦

近期必须验证的技术假设

1. 所有权推断是否能在不显式暴露生命周期的前提下保持可解释的报错
2. MIR 上的 borrow / escape 分析复杂度是否可控
3. FFI 安全包装是否能在零成本和易用性之间取得平衡
4. 基于统一查询系统的 LSP 响应性能是否足够

建议的第一批实现顺序

1. 建立 Rust workspace 与 crate 分层
2. 完成 lexer / parser / AST
3. 完成 HIR、名称解析与基础类型检查
4. 建立 diagnostics 框架与 UI tests
5. 引入 MIR 和基础所有权检查
6. 打通 LLVM IR 到可执行产物
7. 打通 C FFI
8. 再做 LSP 与格式化器增强

当前明确延后

• 宏系统
• 反射
• 深度 C++ 互操作
• 注册中心
• 复杂效果系统
• 非 LLVM 后端

审查重点

你在评审这一版时，最值得重点看的是四件事：

1. 语言设计方向是否足够稳，而不是“特性堆叠”
2. 所有权推断这个核心赌注是否值得押
3. C / Rust / C++ 互操作顺序是否现实
4. 仓库结构是否能支撑几年期的编译器项目

如果这四点成立，后续实现就有明确抓手。