fix(merge_proto): 修复带注释/预处理守卫的proto解析，避免误吞额外内容-ops-cv-AtomGit

已合并

fix(merge_proto): 修复带注释/预处理守卫的proto解析，避免误吞额外内容 #1095

liu-wei创建于 7月7日从liu-wei/ops-cv： master_merge_proto 合入到 cann/ops-cv： master

fix(merge_proto): 修复带注释/预处理守卫的proto解析，避免误吞额外内容 #1095

已合并

liu-wei创建于 7月7日

从liu-wei/ops-cv master_merge_proto合入到cann/ops-cv master

liu-wei成员

7月7日

## 描述 `scripts/util/merge_proto.py` 的 `match_op_proto` / `match_op_proto_extend` 函数内 hard-code 的 regex 有 bug：在带 **前置注释** 或 **头文件 guard** 的 proto 文件上，**贪婪匹配会误吞额外内容**，导致 opname 错位或 op_def 包含不该有的头部。 ### Bug 复现旧 regex： ```python re.compile(r"REG_OP\((.+)\).*OP_END_FACTORY_REG\(\1\)", re.DOTALL) ``` 对如下典型 proto 文件： ```c /* Copyright header ... */ #ifndef OP_AAA_PROTO_H_ #define OP_AAA_PROTO_H_ REG_OP(Add) ... OP_END_FACTORY_REG(Add) #endif ``` 贪婪 `(.+)` 会**尽量多匹配**，跨过注释 + guard 一直吃到文件末尾的最后一个 `)`，导致： - `opname` 捕获到的是 `Add) ... OP_END_FACTORY_REG(Add`（**不是预期的 `Add`**） - backreference `\1` 强制 opname 在 `OP_END_FACTORY_REG(...)` 里**再出现一次**——大多数情况**整个 match 失败**，`match_op_proto` 返回 `None` ### 修复方案把 hard-coded regex 提到模块级 `OP_DEF_PATTERN` 统一两处复用： ```python OP_DEF_PATTERN = re.compile( r"(?:[ \t]*/\*\*?(?:[^*]|\*(?!/))*?\*/[ \t]*\n\s*)?" r"(?P[ \t]*#\s*ifndef\s+\w+[^\n]*\n" r"[ \t]*#\s*define\s+\w+[^\n]*\n\s*)?" r"REG_OP\((?P.+?)\)" r".*?OP_END_FACTORY_REG\((?P=opname)\)" r"(?(guard)[^\n]*\n[ \t]*#\s*endif[^\n]*)", re.DOTALL, ) ``` #### 4 个关键改动 | 改动 | 修复什么 | |---|---| | `OP_DEF_PATTERN` 模块级常量 | 性能（编译 1 次 vs 2 次）+ 行为一致（两处不会漂移）| | `(?P.+?)` 非贪婪 | 关键修复：贪婪 `(.+)` 在多 op / 带注释文件上会误吞内容 | | `(?P...)` 包裹 REG_OP 块 + `op_def = match.group("opdef")` | 关键修复：只取 REG_OP 内部，**op_def 不再带前置注释 / guard**（避免下游 merge_op_proto 拼接时 N 份 license 重复）| | `(?(guard)...#endif...)` 条件回溯 | 捕获完整的 `#ifndef / #define / REG_OP / #endif` 三件套；如果有 guard 就必有 endif，缺一即不匹配（坏源不放过）| | `match.group("opname")` 替代 `match.group(1)` | 命名组比数字下标可读，扩展时不依赖顺序 | | 文件末尾补换行 | POSIX 规范 | ### 关键设计点：为什么 `op_def` 用 `opdef` group 而不用 `group(0)` `match.group(0)` 包含**整段匹配**（comment + guard + REG_OP + #endif）。`match.group("opdef")` 只包含 `REG_OP(...)...OP_END_FACTORY_REG(...)` 内部。 **为什么不带 comment / guard 进 op_def**： - 下游 `merge_op_proto` 拼接到合并文件时会**重复 N 份 license 注释和头文件保护**（N = proto 文件数） - op_def 只需要 **op 自身定义**，注释/guard 是源文件层的语义，跨文件合并时不应该重复 ## 关联的Issue Fixes #605 ## 测试需补充的测试场景（当前 PR 缺 test，可作为 follow-up）： | 场景 | 期望 | |---|---| | 标准 proto（无 comment/guard）| 旧行为完全等价：`opname=Add`, `op_def=Add REG_OP 块` | | 带 copyright 注释 + guard 的标准 proto | 新行为可正确解析（**旧 regex 失败**）| | 1 个 proto 文件含 2 个 op，**共享同一组 guard** | `finditer` 正确返回 2 个 match，opname 各自正确 | | 用 `#pragma once` 而非 `#ifndef` 的 proto | guard group 不匹配（fall back 到只匹配 REG_OP 块），**降级而非崩溃**| | 缺 `#endif`（坏源）的 proto | 条件回溯失败 → `match.group("opdef")` 不匹配，函数返回 `None`（不静默吞错）| | 文件全为 `//` 行注释 + 无 `/* */` | comment group 不匹配（content 是 `[^*]` 仍 ok），只匹配 REG_OP | ## 文档更新无（build 工具细节，不需要用户文档） ## 类型标签 - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [x] ♻️ 重构 - [ ] 🧪 测试 - [x] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧪 代码清理 - [ ] ❓ 其他，请描述：

Pull Request已成功合入, 合并人@CANN-robot

（感谢 liu-wei 的贡献）

liu-wei成员

7月7日创建了 pull request，commit f9aca14b

atomgit-bot

7月7日评论：

变更摘要

此 PR 修复了 scripts/util/merge_proto.py 中 proto 文件解析的正则表达式问题。原有的 REG_OP(...)...OP_END_FACTORY_REG(...) 模式在遇到操作定义前带有注释块（/** ... */）或预处理守卫（#ifndef/#define/#endif）时，会错误地将匹配边界扩展到文件中最先出现的 REG_OP，从而"误吞"额外的无关内容。修复方案是将正则提取为模块级 OP_DEF_PATTERN，在其中将注释和预处理守卫作为可选前缀/后缀，并使用命名捕获组（opname、opdef）精确提取操作名和操作定义本身，使 match_op_proto 与 match_op_proto_extend 两个函数均受益。

主要改动

新增模块级正则 OP_DEF_PATTERN：在文件顶部定义了一个完整的正则表达式，支持可选的 /** ... */ 注释块、可选的 #ifndef/#define 预处理守卫、以及 REG_OP(name)...OP_END_FACTORY_REG(name) 操作定义与可选的 #endif 收尾，使用命名捕获组区分守卫与操作定义。
match_op_proto 改用新正则：将原先内联构造的 op_def_pattern 替换为模块级 OP_DEF_PATTERN，并通过 match.group("opname") 和 match.group("opdef") 获取结果，避免回退引用 \1 可能匹配到错误内容。
match_op_proto_extend 同步更新：同样替换为 OP_DEF_PATTERN.finditer 并使用命名捕获组获取每次匹配的操作名和操作定义，使多个操作定义场景下的解析保持一致且准确。

atomgit-bot

7月7日评论：

代码审查

审查总结

对变更文件 scripts/util/merge_proto.py 进行了全面审查，分析结果：

P0: 0 个
P1: 0 个
P2: 0 个
P3: 1 个

已审查的文件：

scripts/util/merge_proto.py — 发现 1 个 P3 问题（条件 #endif 匹配过于严格，守卫特性为死代码）

整体风险评估：低风险。此变更将行内编译的正则表达式提升为模块级预编译常量，并用命名捕获组替代数字索引，提升了代码可读性和可维护性。新增的 doc comment 和预处理守卫匹配逻辑对于当前仓库中的所有实际 proto 文件均能正确回退到核心 REG_OP 块匹配，不会产生错误输出。唯一的低优先级问题是守卫+endif 条件匹配过于严格导致该子特性在当前仓库中从未生效，但回退行为保证了功能正确性。

⚠️ 已识别出整体风险，但无法提取行内评论，请参考整体评估。

任务名称	状态	日志	下载链接
Compile_Ascend_X86	✅ SUCCESS	>>>>>	>>>>>
Compile_Ascend_X86_mobile_station	✅ SUCCESS	>>>>>	>>>>>
Compile_Ascend_ARM	✅ SUCCESS	>>>>>	>>>>>
Compile_Ascend_X86_experimental	✅ SUCCESS	>>>>>	>>>>>
Compile_Ascend_ARM_experimental	✅ SUCCESS	>>>>>	>>>>>
Compile_Ascend_X86_A5	✅ SUCCESS	>>>>>	>>>>>
Compile_Ascend_ARM_A5	✅ SUCCESS	>>>>>	>>>>>
pre_comment	✅ SUCCESS	>>>>>
Compile_Pre	✅ SUCCESS	>>>>>
Compile_Ascend_X86_ubuntu24	✅ SUCCESS	>>>>>	>>>>>
Compile_Ascend_X86_mobile_station_ubuntu24	✅ SUCCESS	>>>>>	>>>>>
Compile_Ascend_X86_experimental_ubuntu24	✅ SUCCESS	>>>>>	>>>>>
Compile_Ascend_X86_A5_ubuntu24	✅ SUCCESS	>>>>>	>>>>>
Compile_Ascend_ARM_ubuntu24	✅ SUCCESS	>>>>>	>>>>>
Compile_Ascend_ARM_experimental_ubuntu24	✅ SUCCESS	>>>>>	>>>>>
Compile_Ascend_ARM_A5_ubuntu24	✅ SUCCESS	>>>>>	>>>>>
Compile_X86_monitor_910b	✅ SUCCESS	>>>>>	>>>>>
Compile_X86_monitor_910c	✅ SUCCESS	>>>>>	>>>>>
Compile_X86_monitor_950	✅ SUCCESS	>>>>>	>>>>>
Compile_classify	✅ SUCCESS	>>>>>
Compile_harmony-infer-chs-cv	✅ SUCCESS	>>>>>
Compile_harmony-infer-chs-cv-1	✅ SUCCESS	>>>>>
UT_Test	✅ SUCCESS
PreSmoke_A900	✅ SUCCESS		>>>>>
API_Check	✅ SUCCESS	>>>>>
PreSmoke_ATK_Test_A2	✅ SUCCESS		>>>>>
UT_Test_report_lcov	✅ SUCCESS

任务名称	状态	日志
codecheck	✅ SUCCESS	>>>>>
SCA	✅ SUCCESS	>>>>>
antipoison	✅ SUCCESS	>>>>>
codecheck_checkpr	✅ SUCCESS
StaticCheck_codespell_check	✅ SUCCESS
StaticCheck_link_validity_check	✅ SUCCESS
StaticCheck_resource_existence_check	✅ SUCCESS
StaticCheck_tag_closed_check	✅ SUCCESS
StaticCheck_markdownlint	✅ SUCCESS
codecheck_codestyle	✅ SUCCESS	>>>>>
codecheck_precommit	✅ SUCCESS	>>>>>

Pull Request已成功合入, 合并人@CANN-robot

变更摘要

代码审查

审查总结

CLA Signature Pass

PR Approval Progress

Module Approval Details