# 把火山编译器搬到了鸿蒙，目前是个半成品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工作区中先读取再让他动工,愿大家工作顺利。
|Archiver|手机版|小黑屋|递归火山软件开发平台
( 鄂ICP备18029190号 )
发表于 
QQ好友和群
收藏
分享
淘帖
