CLA协议签署
当前Pull Request的提交暂无外部代码贡献者合并受阻
PR创建成功通知 | 感谢您的贡献 🎉
您好！系统已检测到您成功创建 Pull Request（PR），感谢您对项目的支持与参与！以下几点需要您着重关注：
一、PR必须关联Issue ❗️
触发门禁检查的必要步骤：在PR描述框输入Issue完整链接，完成Issue关联。
请注意，一个 Issue 不能同时关联同一 base 仓库内同一个分支的多个开启状态的 PR
二、门禁触发规则 🔧
- 门禁类型判定：由Issue关联的PR所属代码仓数量决定
- 关联多个代码仓PR：触发「多仓联合门禁」
- 关联单个代码仓PR：触发「单仓门禁」
- 启动指令与检查范围：需主动回复指令：
- 回复 "start build"：执行Cangjie的主要基础检查，包含commit格式检查、静态告警分析、OAT开源声明检查、多平台构建、单元/集成测试等
- 关联同一issue的多个PR，仅需在任意一个PR里回复触发一次门禁，该PR门禁通过后，所有PR都会添加Label和测试人
- 每个pr只能同时运行一条CI流水线，如需重新启动，请先关闭运行中的，再评论触发门禁
- Markdown修改仅触发文档类构建测试门禁，不会触发Cangjie的编译测试门禁
- commit 信息格式请遵循：Conventional Commits 规范
- 请保证每一条 commit 都已添加
Signed-Off-By信息 - 回复 "start build cov"：执行覆盖率构建工程，生成该提交的增量代码覆盖率报告
三、合入条件 ⚠️
- 满足最低评审人数，且评审问题需全部解决；
- 禁止合入本人创建的PR，需由其他协作者操作；
- 合并前确保关联流水线任务运行成功（build-test-passed）；
- 需求类覆盖率门禁：当关联的 Issue 标题以
[feature]:开头（需求类 Issue）时，联合提交中属于cangjie_compiler、cangjie_runtime、cangjie_stdx、cangjie_tools、llvm-project仓库的 PR，必须先回复 "start build cov" 触发增量覆盖率流水线并通过，使 PR 获得cov-test-passed标签后方可合入。
四、合并PR ✅
回复 "start merge"，CI流水线会自动检查所有关联PR的状态、版本号标签、检视意见密度、兼容性、需求类覆盖率门禁，若所有PR都满足合并条件，则将会同时合并所有PR。若存在不满足合并条件的PR，则不会合并任何PR。
如果希望不进行兼容性相关的检测，请任一合法审查人复制以下内容，在 start merge 前提交评论：
本 pr 不需要兼容性相关检测，对于引发的任何兼容性问题（即由于本 pr 合入将导致用户需适配代码的话），由本人承担。
If you wish to avoid compatibility-related checks, please have any approver copy the following content and submit it as a comment before sending start merge:
This PR does not require compatibility-related checks. For any compatibility issues caused by this PR (i.e., if the integration of this PR will require users to adapt their code), I will take full responsibility.
五、补充说明 📢
- 详细仓颉贡献流程：贡献流程(Cangjie Community Contribution)
- 门禁结果将自动评论至关联的所有PR，敬请留意。
[minor] mangledCopy 的深拷贝可以随这次重构一起消除
问题：T mangledCopy = mangled; 仍在函数开头，但重构新增的三条早返回路径（'k'、MANGLE_COMPRESS_PREFIX、IsPrimitiveType）都用不到它——它只被 ForwardCompoundType 之后的 TreeIdMapAssign 使用。
影响：ForwardType 是逐类型节点递归调用的，primitive 在类型流里占比很高（PRIMITIVE_PREFIX_SET 覆盖 18 种），每次都白拷一次字符串。
建议：把这一行下移到 size_t nextIdx = ForwardCompoundType(...) 的前一行即可（必须在它之前，因为解压会改写 mangled）。这次重构正好把边界摆出来了，顺手做掉成本很低。
[nit] ForwardCompoundType 的 ch 形参冗余：函数已经拿到 mangled 和 idx，唯一调用点传的就是 mangled[idx]，多一个参数就多一处可能与 idx 不同步的状态。
[nit]
改动后 #ifndef BUILD_LIB_CANGJIE_DEMANGLE 分支只剩 "Base/CString.h"，std::vector<std::string> genericVec 是无条件的。本仓内没有 Base/CString.h，那条分支在本仓不可构建，所以这处移动在本仓无实际影响；但 runtime 仓走的正是这条路径，那边
[major] 同目录下 Utils.h 未同步，MANGLE_STDPKG_MAP 存在真实的 demangle 结果分歧
（本条与本行代码无关，因 Utils.h 不在本次 diff 内，借 DemanglePackageName 内这处改动提出）
问题：issue #1123 的复现步骤指向的是三个 demangler 目录，本次只同步了其中 4 个文件。我把三仓 head 上另外 5 个共享文件也比了一遍，全部未同步：CangjieDemangle.cpp / CangjieDemangle.h / Utils.h / StdString.h / Cjfilt.cpp。其中 Utils.h 的 MANGLE_STDPKG_MAP 条目数为 compiler 65、runtime 68、本仓 65，runtime 独有 {"aa", "std.ad"}、{"bp", "std.net.native.cjvm"}、{"br", "std.ffi.java"} 三条。
影响：这张表在 DemanglePackageName 里直接决定包名还原，同一个 mangled 名在 runtime 与 cjfilt 下会 demangle 成不同结果——正是 #1123 要消灭的那类不一致。另外 StdPkgHash 的 + static_cast<uint8_t>(cPkg[id++])（compiler）与 + cPkg[id++]（runtime/tools）也未对齐，因键都是 2 字符 ASCII 暂不触发差异。
建议：本轮补上 Utils.h 的这三条映射；其余文件若不在本轮处理，请在 PR 描述里写明「本次只同步 4 个文件」以及剩余分歧与 #1123 的关系，否则 issue 关掉后这部分不一致就无人认领。
[nit] ForwardTypes 的形参名声明与定义不一致
（借本行提出：真正要改的是本文件 line 138，它不在本次 diff 内）
本文件 line 138 的声明是 size_t ForwardTypes(T& mangled, size_t& cnt, size_t idx = 0);，而 DeCompression.cpp 的定义用的是 startId（runtime 两处都是 startId，写法自洽）。这一行也是本次同步后三仓 DeCompression.h 仍存在差异的唯一原因，建议统一成 startId。
变更内容（必填）
同步 compiler, runtime, and tools 三仓demangle代码
变更类型（必填）
请描述本次Pull Request变更类型（原因），请在保存后点击复选框或在编辑时将对应项前面的
[ ]改为[X]。变更内容自检（必填）
请勿修改或删除以下选项内容，请在保存后点击复选框或在编辑时将对应项前面的
[ ]改为[X]。编译本地自验证结果：
测试用例本地自验证结果：
关联的issue（必填）
https://gitcode.com/Cangjie/cangjie_compiler/issues/1123