用AI制作一个火山语法鸿蒙编译器的体验[开源] - 递归火山软件开发平台

(, 下载次数: 1)

(, 下载次数: 1) (, 下载次数: 1)

# 把火山编译器搬到了鸿蒙，目前是个半成品0.1版本，属于实验，但能跑了

因为我的token燃烧殆尽,所以你想让他继续,加载进工作区,燃烧后跟帖即可,来一场接力。

> 写这篇文章不是为了吹，是为了在它还没变成"另一个永远写不完的迁移工具"之前，
> 找几个愿意一起填坑的人。

## 先说结论

这是一个把"火山视窗"编译器搬到鸿蒙 ArkTS 的工具。**目前是半成品**。

具体来说：

- 能跑了：基本类型、类继承、虚拟方法、属性访问器、参考参数、文本累加、
类库组加载、数值保护——这些都能从 `.wsv` 翻成 `.ets`。
- 还没做：ArkUI 那 41 条规则、类库本身的批量翻译、hvigor 打包 HAP。

换句话说，**业务逻辑能翻过去，界面不能；类库能加载但不能调用**。
听起来挺尴尬对吧？但比起"另一个从零写的迁移工具"，至少它的前端是
**作者亲自调过的 53 个 C ABI 导出**，逐字节跟出厂版本对齐。前端这关我先趟了。

## 我为什么要做这个

火山视窗是一套中文 Windows 开发环境，配套一个 C++17 写的编译核心 `volcc`。
它有个很妙的特点：**前端做完解析后，得到的 `ProjectModel` 正好是
"类、方法、参数、继承"的形状**——这跟 ArkTS 几乎是一一对应的。

两套语言看似无关，但其实共享一个底层结构：强类型、面向对象、带静态方法。

所以我就琢磨：**能不能把后端的"AST → C++ 文本"换成"AST → ArkTS 文本"，
让同一份 `.wsv` 工程既出 Windows 程序，也出鸿蒙 ArkTS 工程？**

这件事没人做。所以我自己动手了。然后发现坑比想象的多。

## 第一个大坑：MSVC 把我的中文路径写成乱码

这事儿说起来挺丢人。我把生成器写完，跑 `--gen-only`，exit 0，皆大欢喜。
然后我去输出目录一看——**0 个文件**。

我：？？？

排查了半小时，发现文件其实写了，只是写到了一个叫
`D:\鐏北楦胯挋\` 的目录里。MSVC 的 `std::filesystem::path(std::string)`
会按 ANSI 代码页解码 UTF-8 字符串，把 `火山鸿蒙` 解释成一坨乱码。

修复方法是全部改成 `std::filesystem::u8path`，并在开源手册里立了条铁律：

> **新增路径 API 必须用 `u8path`。**

后来我把这条铁律写进了"提交前检查表"，希望能帮下一个踩坑的人省点时间。

## 第二个大坑：编译核心会去找一个叫 `base.vgrp` 的东西

火山原工具链的逻辑是：加载工程 → 加载类库 → **去找类库运行时根目录里的
`base.vgrp` 之类的基础库** → 找不到就报一堆 `VOLCC2966/2977`。

问题是：迁移包没随附这些基础库。所以 ArkTS 工程一加载就报错。

修复方法：在 `project_build.cpp` 里**前置分支**——ArkTS 目标直接绕过
`build_translation_compilation_context`，进 `generate_arkts_project`。
原因很简单：ArkTS 只生成源码，根本不需要类库运行时根。

但这就引出了第三个坑。

## 第三个大坑：类库加载了，但类库自己有毛病

`.vgrp` 链路打通后，类库源文件能进 `ProjectModel` 了，但它们一进来就报：

```
VOLCC2201 找不到类"YYJSON只读对象类"的基础类"扩展对象类"
```

因为随附类库缺 `扩展对象类`（属于 `base.vgrp`，没随包）。这是类库本身的
问题，跟用户工程无关。如果让这种错误阻断生成，那任何引用类库的工程都
跑不动——等于白做。

所以 ArkTS 目标把**类库源的诊断降级为 `warning`**，只让用户源码的
错误阻断生成。一个简单的路径集合比对：

```cpp
if (paths.count(path) != 0) diagnostic.severity = Severity::warning;
```

效果：用户工程能跑过编译，类库自身的问题只是 warning。

## 然后我意识到：光"加载"不够，得"降级"

火山有些语义 ArkTS 没有：

- **按引用传递**——ArkTS 没有这东西。
- **文本原地修改**——ArkTS 的 `string` 不可变。
- **整数类型有范围**——ArkTS 的 `number` 是浮点，整数字面量越界会静默丢精度。

如果直接按值翻译，前两个会**静默丢语义**（写不回、性能差），第三个会
**静默丢精度**。这些都比"报错不生成"危险得多。

所以做了三套降级包装：

| 火山语义 | ArkTS 降级 |
|---|---|
| 参考参数 / `@需求类型 = 可写入变量` | `Ref<T>` 单元，调用方持有，读写经 `.value` |
| 文本原地累加 `s = s + a` | `TextBuilder`，改写为 `s.append(a)` |
| 整数除零 / 越界字面量 | 编译期拒绝，`VOLCC4101` |

其中最有意思的是 `TextBuilder` 的判定——**不是所有 `文本` 都要降级**，
只对"原地累加"的才换。判定条件是 AST 形状：

> 赋值语句满足 `名字 = 名字 + a + b …`（左结合 `+` 链、链首同名）。

为什么这么挑剔？因为如果只看"类型是文本"就降级，那 `let s: string = "hi"`
也会被改成 `TextBuilder`，纯属找麻烦。判定必须看**形状**，不能看**类型**。

这条铁律也写进了开源手册：**降级判定看 AST 形状，不看源码文本**。

## 还有几个"不做"的决定

这些是我反复纠结后选择**不做**的：

1. **不做隐式包装**。火山的 `自增(普通值)` 在 ArkTS 没有等价写法
（值传递无法回写）。要求调用者显式声明 `参考` 变量，否则报错。
我宁可让用户改代码，也不生成 `自增(new Ref(普通值))`——后者
等于在调用点开新单元，**值写回不到原变量**，是静默丢语义。

2. **不做 ArkUI 自动迁移**。火山的可视化设计器输出是另一套数据，
本工具只翻译 `.wsv` 里的类语义。强行译 UI 会产出一堆不能用的 struct，
不如让用户手调布局，但业务逻辑全部翻译过去。

3. **不做运行期数值保护**。除零、整数溢出回绕这些只在编译期判定。
运行期值是 `number`（浮点），ArkTS 自己会按 IEEE 754 处理——
我不打算在 ArkTS 里重新发明整型。

每一条都对应一个被踩过的坑。**复制本工具的人，请把这些"不做"原封不动
抄到自己的设计文档里——它们是语义正确性的护栏。**

## 现在能干什么

截至 2026-10-26：

| 能力 | 状态 |
|---|---|
| 53 个 C ABI 导出全部按原工具链工作 | 9/9 行为等价 |
| ArkTS 类/方法/局部/if/while/基本类型 | 完成 |
| 继承/虚拟覆盖/重载/属性访问器/常量类 | 完成 |
| 绑定层（成员/方法解析、参考参数校验） | 完成 |
| `Ref<T>` / `TextBuilder` / 数值保护降级 | 完成 |
| 类库组（`.vgrp`）加载与诊断 | 完成 |
| ArkUI 41 条规则 | 待开始 |
| 类库批量翻译（B1→B4） | 待开始 |
| hvigor/HAP 打包 | 待开始 |

**回归**：`verify-p0.ps1` 9/9 PASS，10 个样例矩阵全部命中预期。

## 三行命令试一试

环境备好（VS2022 Build Tools + CMake + .NET 8）后：

```powershell
powershell -ExecutionPolicy Bypass -File .\P0-构建工程\build.ps1
powershell -ExecutionPolicy Bypass -File .\P0-构建工程\verify-p0.ps1
.\P0-build-out\vs2022-x64\out\volcc_cli.exe --build-vprj `
  .\P0-build-out\samples\arkts-semantics\arkts-semantics.vprj `
  --classlib ".\AI火山编译器\作者编译后的\核心库" `
  --out .\P0-build-out\arkts-out --gen-only
```

跑通后看 `.\P0-build-out\arkts-out\ets\` 下的 `.ets`——那就是从火山 WSV
翻译出来的 ArkTS 源码。

## 它不是什么

为了避免你期待过高，明确说一下它不是什么：

- **不是"鸿蒙版火山视窗"**。火山 IDE 是另一套东西，本工具只用它的编译核心。
- **不是"ArkUI 迁移工具"**。UI 还没做，目前只能译业务逻辑类。
- **不是"代码到代码正则替换"**。本工具直接吃解析器 AST。
- **不是"成品"**。这是个半成品，半成品，半成品（说三遍）。

## 接下来要做什么

按优先级：

1. **P5 ArkUI 界面生成**——最重头戏，41 条规则分批接入。
2. **P6 类库批量迁移**——从 `hx_yyjson` 开始，让跨库调用能真正工作。
3. **P7 hvigor/HAP 工具链**——把产出的 `.ets` 真正打成 HAP，跑在模拟器上。

这三块都需要更多手。如果你对编译器前端复用、ArkUI 迁移、类库批量翻译
任何一个方向感兴趣，欢迎一起做。

完整的阶段设计与验收记录在
[火山视窗到ArkTS-迁移方案手册.md](../火山视窗到ArkTS-迁移方案手册.md)，
操作手册与配方在 [开源手册](../开源手册/) 目录。

## 最后说一句

我做这个不是为了"开源一个完美工具"，是为了**把一个已经存在的、
做得不错的前端**救出来，让它不至于只通向 Windows。

火山的前端写得很好，TypeSystem 和诊断体系都很扎实，丢在 Windows 一棵树上
可惜了。鸿蒙生态现在缺的就是"中文友好的、可复用的前端资产"。

如果你也在为已有的 WSV 工程找一条转鸿蒙的路，或者对编译器前端复用感兴趣，
欢迎一起来填坑。**坑我已经趟了一半，剩下的我们一块儿趟。**

以上内容让trae写的。

开源包放在下面了,你可以直接加载进任何一个AI工作区中先读取再让他动工,愿大家工作顺利。