工具链
一门语言能不能被真正使用，多半不取决于语言本身，而取决于周边。这一页列的是围绕 Loment 建起来的东西，以及每一项的判据。
| 工具 | 做什么 | 判据 |
|---|---|---|
| loment | 命令面本身：38 条命令、六个分区 | 是用 Loment 写的（loment/tools/lomcli.lomt，约 2300 行），链成 bin/loment-cli；bash 与 batch 两个启动器各加一行转发就完事——否则 30 多条命令要在两份启动器里各写一遍并保持同步。判据里有一条：目录里的每一条命令都真能分发，不是「查得到、敲下去说未知命令」；还有一条要求每条命令的输出是纯 ASCII（936 代码页控制台上中文必乱码）。lib / pkg 故意不在里面（发行包没有 Python），lompi 也不在（它是另一个命令）。 |
| lomfmt | 格式化器 | 已用 Loment 重写，与 Python 版逐字节相同（42 语料 + 4 边界 + 幂等）。这是工具链去 Python 的第一块——它只吃词法层，所以不受自举 parser 的子集限制。 |
| loment_lsp | 语言服务：补全 / 跳转 / 诊断 | 已用 Loment 重写（loment/tools/lsp.lomt），装它不需要 Python；VS Code 扩展 6/6 无头验收含完整 LSP 往返；编辑器内人工点验待做 |
| lompkg | 包管理器：依赖解析 + 校验和 | 已用 Loment 重写（loment/tools/lompkg.lomt），stdout 与退出码都与 Python 版逐字节相同；拓扑序、sha256、环检测、锁往返全部由它自己做——目录遍历与哈希用 syscall 自备，没往运行时里加东西。 |
| lib （源码仓库侧） | 库系统：依赖树 / 实例身份 / 能力闭包 / 冲突检查 / 物化 | 这是与上面那个包管理器不同的一层，而且只在源码仓库里可用（python tools/loment.py lib ...）——发行包没有 Python，所以发行版的 loment 里没有这条命令。一个库就是一个目录；依赖是源码里的 use，不用另行声明；实例身份是递归哈希；多个版本靠物化改名共存；能力需求是从 guard 推导出来的，不由作者手写。写库没有新东西要学——见「写一个 Loment 库」。 |
| lompi | 库管理工具：清点仓库 / 依赖树 / 发锁 / 验锁 / 落盘计划 | 第一个库管理工具，也是用 Loment 写的独立程序——入口加七个模块编成一个可执行文件，跑起来不需要 Python。从 0.1.4 Alpha2.3 起随 Loment 一起安装，装好就在 PATH 上。它自己读源码里的 use 找依赖，自己算身份（递归哈希），发出来的锁是身份清单而不是版本清单。但它不是 Loment 官方工具——loment help 里没有它，loment 也不转发给它：装在一起不等于它是同一件工具的部件。见 Lompi 一页。 |
| lomdoc | 从 .lomt 生成 API 文档 | 已用 Loment 重写（loment/tools/lomdoc.lomt），与 Python 版逐字节相同；文档与编译器同版本 |
| loment-lomelf | 链接器：把 IR 变成可执行文件 | 仓库自己的第三个后端。同一份 IR 链出 Linux ELF 或 Windows PE，产物与 clang 路行为逐值一致；自举镜像产出的可执行文件与参考实现逐字节相同。包里自带，不需要 clang，也不需要 WSL |
| loment ir | 一条命令同时看 IR 与机器码 | 输出可读、与目标一致；反汇编走原生后端，不经 clang |
| test / bench / cov （开发侧） | 内建测试、基准与 IR 级覆盖率 | 这三条不在发行版的 38 条命令里——它们是开发侧入口 python tools/loment.py 的子命令。测试 4/4 PASS；覆盖率报告可复现；bench / cov 两条仍外调 clang。 |
| dbg （开发侧） | 符号化：按符号名断点、源行映射 | “不再读二进制”——编译器导出语义，调试器直接消费 |
编辑器
语言服务不绑定 VS Code——它是一个普通的 stdio LSP，命令行与编辑器设置里填的值完全一样。高亮是两份 TextMate 语法（.lomt / .lom），两边共用同一份词表，所以不会各说各话。
| 去哪儿写 | 怎么装 | 得到什么 |
|---|---|---|
| VS Code | editors/vscode/，打包用 tools/vscode_ext.py |
两份语法 + LSP（补全 / 跳转 / 诊断 / 格式化）+ 6 个命令；无头验收 6/6 |
| Vim | 在 vimrc 里加 set runtimepath+= 指向仓库的 editors/vim；零插件、零 Python |
高亮，以及 :LomentCheck 把诊断接进 quickfix、:LomentBuild 出 .ll/.elf；判据 2/2 |
| 任意 LSP 客户端 | 指向 scripts/install-lsp.ps1 装好的那个服务（Windows 上原生跑，不经 WSL） |
补全 / 跳转 / 保存即诊断。装服务本身不需要 Python——服务也是自举编译器编译出来的 |
| 不开编辑器 | powershell -File scripts/lomc.ps1 FILE -Run（只用种子 + 原生后端） |
编译并运行一个 .lomt，全程无 Python。编译与运行都在本机原生完成：Windows 上出 PE，Linux 上出 ELF——两边都不经 WSL，也不需要 clang |
| Windows 文件关联 | python tools/loment_filetype.py --register（只写 HKCU，不需要管理员） |
.lomt / .lom 成为真实文件类型：双击进编辑器，「打开方式」里常驻，资源管理器里有自己的图标 |
这条路上还缺什么：
编辑器内格式化还没走 Loment 版（语言服务未声明
documentFormattingProvider），命令行仍可用 lomfmt；诊断文案是分类标题（如 E013 重名），不是参考实现的完整措辞。
构建性能
82.6 ms
冷构建
9.0 ms
热构建（增量 + 内容哈希缓存）
错误信息
诊断码是 E001–E021，二十一类，每一类都带一条可执行的修复建议。两条纪律让它不只是一张表：码按修法分，不按消息措辞分——「实参类型」「载荷类型」「return 类型」都归 E001，因为用户接下来要做的是同一件事；顺序即优先级，E002 必须排在 E001 前（「载荷类型 Foo 未声明」要做的是先声明 Foo）。判据有两条：13 条反例片段逐条被分类（无 E999）且带建议；以及用 AST 抽出参考实现里全部 81 条消息模板逐条分类——分类表漏掉一条，那条规则会在「自举 vs 参考」的码集对照里两边都成 E999，缺口就这样静默消失。
编译器内部的那套工具链是另一回事：
内核自带汇编器 → 链接器 → C 子集编译器（fujocc）。那是 FujoOS 的，不是 Loment 的——见 开始 · 构建内核。