PR创建成功通知 | 感谢您的贡献 🎉

您好！系统已检测到您成功创建 Pull Request（PR），感谢您对项目的支持与参与！以下几点需要您着重关注：

一、PR必须关联Issue ❗️

触发门禁检查的必要步骤：在PR描述框输入Issue完整链接，完成Issue关联。

请注意，一个 Issue 不能同时关联同一 base 仓库内同一个分支的多个开启状态的 PR

二、门禁触发规则 🔧

1. 门禁类型判定：由Issue关联的PR所属代码仓数量决定
   • 关联多个代码仓PR：触发「多仓联合门禁」
   • 关联单个代码仓PR：触发「单仓门禁」
2. 启动指令与检查范围：需主动回复指令：
   • 回复 "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，敬请留意。

secbot 白盒检视中

⏳ 正在进行兼容性检测中，可能需要2~3分钟，请稍候，若10分钟无检测结果，请重新回复 start merge。

⏳ Compatibility check in progress. It may take 2–3 minutes. Please wait. If there is no result after 10 minutes, please reply with start merge again.

✅ 合入前兼容性检测通过。
涉及仓库：Cangjie/cangjie_compiler, Cangjie/cangjie_stdx, Cangjie/cangjie_test

结论

• 分析过程：仅分析了用户指定的 Cangjie/cangjie_compiler#2147 与 Cangjie/cangjie_stdx#815。核对了 24 个变更文件，重点检查 CHIR 的 Attribute 位图、StdxChirFormat.fbs、compiler/stdx 序列化与反序列化，以及两仓组合 head 的编号对应关系。compiler#2147 在 Attribute 枚举尾部保留 DOES_NOT_THROW=38、OBJ_C_IMPL=39，并新增 MATCH_PATTERN=40、PLUGIN_ADDED=41；stdx#815 则将 DoesNotThrow=38、MatchPattern=39、PluginAdded=40，未包含 ObjCImpl，组合后编号不对齐。Only the user-specified Cangjie/cangjie_compiler#2147 and Cangjie/cangjie_stdx#815 were analyzed. The 24 changed files were reviewed, focusing on the CHIR Attribute bitmap, StdxChirFormat.fbs, compiler/stdx serialization and deserialization, and numeric alignment at the combined heads. compiler#2147 keeps DOES_NOT_THROW=38 and OBJ_C_IMPL=39, then adds MATCH_PATTERN=40 and PLUGIN_ADDED=41; stdx#815 maps DoesNotThrow=38, MatchPattern=39, and PluginAdded=40 while omitting ObjCImpl, so the combined heads are misaligned.
• 原因：存在兼容性破坏。跨 compiler/stdx CHIR 插件边界传递的是原始 UInt64 属性位图，位号属于跨组件序列化契约。当前组合中，compiler 的 include/cangjie/CHIR/IR/AttributeInfo.h 将位 39 解释为 OBJ_C_IMPL、位 40 解释为 MATCH_PATTERN、位 41 解释为 PLUGIN_ADDED；但 stdx 的 src/stdx/chir/attribute.cj 将位 39 解释为 MatchPattern、位 40 解释为 PluginAdded。结果是 compiler 发送的 OBJ_C_IMPL 会在 stdx 中被误识别为 MatchPattern，compiler 发送的 MATCH_PATTERN 会被误识别为 PluginAdded，而 PLUGIN_ADDED 位 41 在 stdx 当前枚举中没有对应项；反向序列化后 compiler 也会以不同语义读取这些位。这会破坏插件往返后的 CHIR 元数据与不可达分支分析，且两个输入 PR 的组合 head 未形成声明端、序列化端、消费端一致的适配闭环。应在 stdx 中保留 ObjCImpl=39，并将 MatchPattern、PluginAdded 对齐到 compiler 的 40、41（或双方显式固定并统一全部位号）后再视为兼容。This is incompatible. The compiler/stdx CHIR plugin boundary transports the raw UInt64 attribute bitmap, making bit positions a cross-component serialization contract. In the current combined heads, include/cangjie/CHIR/IR/AttributeInfo.h interprets bit 39 as OBJ_C_IMPL, bit 40 as MATCH_PATTERN, and bit 41 as PLUGIN_ADDED, while src/stdx/chir/attribute.cj interprets bit 39 as MatchPattern and bit 40 as PluginAdded. Consequently, compiler-emitted OBJ_C_IMPL is read by stdx as MatchPattern, MATCH_PATTERN is read as PluginAdded, and PLUGIN_ADDED at bit 41 has no corresponding stdx entry; the reverse round trip is likewise decoded with different meanings by the compiler. This corrupts CHIR metadata and unreachable-branch analysis after plugin round trips, so the two PR heads do not provide a consistent declaration-serialization-consumer adaptation. stdx should preserve ObjCImpl=39 and align MatchPattern and PluginAdded to compiler bits 40 and 41, or both sides should explicitly assign and unify all bit values.但相关修改已完成审视（CHG-20260917-C22CFB61），视为合法变更。But the review process has been completed for the relevant modifications (CHG-20260917-C22CFB61) and is considered as a legal change.
• 结论：兼容

✅ 以下PR将同时合入：

• Cangjie/cangjie_compiler#2147: feat(chir): refine unreachable match regions
• Cangjie/cangjie_test#2167: test(chir): align unreachable region diagnostics
• Cangjie/cangjie_stdx#815: feat(chir): preserve unreachable match metadata

✅ The following PRs will be merged simultaneously:

• Cangjie/cangjie_compiler#2147: feat(chir): refine unreachable match regions
• Cangjie/cangjie_test#2167: test(chir): align unreachable region diagnostics
• Cangjie/cangjie_stdx#815: feat(chir): preserve unreachable match metadata