[增强建议] 为 HCCL/HCOMM 仓库新增函数复杂度控制类静态检查

补充完整 issue 内容：

此 issue 提议为 HCCL/HCOMM 仓库新增函数复杂度控制类静态检查，核心配置如下：

• 函数行数：50 行（华为编程规范）
• 函数语句数：50 语句
• 分支数量：15 分支
• 参数数量：6 参数
• 嵌套深度：4 层
• 认知复杂度：25

详见上文更新后的完整方案。

建议直接使用现有的precommit集成
参考：https://gitcode.com/openlibing/docs/blob/main/static-code-analysis/tools/Clang-Tidy.md

提交了两个pr，有指导文档指导怎么配置到ci静态告警任务上呢？
https://gitcode.com/cann/hccl/pull/2494，
https://gitcode.com/cann/hcomm/pull/4438

可以把入口补充到precommit中，使用precommit的拦截能力，完成本地验证和线上验证的统一

/close

Notice

@mywaaagh_admin , this issue is linked to an open PR. Please merge the PR before closing this issue.

待相关PR合入后即可关闭

进展更新（2026-10-20）

配套 PR 第二轮修复完成并推送，拦截链路补齐：

hcomm#4438（开启中）：

• 修复全部 6 条检视意见：HIGH cwd 漏检根因（仓库根解析+chdir）、MEDIUM×3（parse_warnings 保留 file 字段防头文件误拦 / clang-tidy 返回码检查不静默 PASS / base-ref 按 upstream→origin 回退+显式 refspec）、LOW×2（HeaderFilterRegex 锚定路径段边界 / 新增仓内单测接入 UT 流程）
• 新增发现并修复：CMake 未导出 compile_commands.json 导致检查从未真正执行，已加 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
• 新增 scripts/clang_tidy_check_test.py 单测 8 用例，接入 build.sh UT 流程

hccl#2494（已重新开启）：

• 同源修复全部同步，两仓脚本完全一致（仅 .clang-tidy 仓名/issue 注释不同）

豁免机制（特殊情况屏蔽）：

• // NOLINT(check) / // NOLINTNEXTLINE(check) 原生抑制（.clang-tidy 注释说明）
• 无 compile_commands.json 条目的变更源文件（生成/第三方代码）显式跳过并打 WARNING
• 变更头文件无编译条目时 standalone -x c++ 分析，新增复杂度仍被拦截

验证：python 单测 8/8（Windows + Linux 双平台）；WSL clang-tidy 14.0.1 真实验证 8 场景全通过（新增违规 exit 1 拦截 / NOLINT 与 NOLINTNEXTLINE 豁免 / 存量行告警过滤 / 第三方跳过 / 头文件 standalone 拦截 / build 子目录 cwd 无关 / 配置 dump 解析）。

剩余基础设施侧动作（@songchangxia）：CANN Compile 镜像预装 clang-tidy（yum install -y clang-tools-extra）。镜像装好后，两仓 CI Compile 任务构建后即真实拦截新增代码复杂度违规。

最终状态（2026-10-20 23:20）

两配套 PR 均已完成第二轮修复、CI 全绿、全部合入门禁通过，等待 committer 合入：

• hcomm#4438：mergeable=True，conflict/ci_state/resolve_discussions/approval_* 全通过（9 条行级检视意见全部答复并 resolve，含 jiyuanhao 两条历史提问）；标签 cann-cla/yes + api-check-pass + ci-pipeline-passed
• hccl#2494：已重新开启，同源修复，同样全部门禁通过

交叉验证（glm-5.3 独立模型）发现的 HeaderFilterRegex YAML 引号 bug 已修复并新增真实场景验证；两轮累计修复：6 条检视意见 + compile_commands.json 未导出（拦截从未生效的关键修复）+ ACMR 重命名覆盖 + 分析失败阻断 + set -e 日志死代码。

剩余动作：

1. 请 committer 合入两 PR（作者无 PUSH 权限，merged_by_user_passed 待满足）
2. 基础设施侧 Compile 镜像预装 clang-tidy（@songchangxia，yum install clang-tools-extra，≥12 版本），装后 CI 即真实拦截新增代码复杂度违规
3. 两 PR 合入后本 issue 可关闭

第三轮完成（2026-10-21）

两 PR 第三轮修复已推送并通过 CI（双仓 ci-pipeline-passed）：

• hcomm#4438（11d74e705）/ hccl#2494（f8bd3d38）

1. 检视意见：三个脚本移入 scripts/clang-tidy/ 目录（路径全量同步，无残留）
2. .clang-tidy 注释白话化：规则表（7 项阈值含义）、检查范围（全仓 C/C++ 变更文件）、NOLINT/NOLINTNEXTLINE 屏蔽示例、执行时机（默认构建后，非 UT）、缺依赖行为（不自动下载+WARNING 跳过+安装命令）、一分钟自测配方
3. CI 实证（v8 日志）：Compile 任务日志出现 "Running clang-tidy incremental check"——新路径真实执行；UT 任务日志 "Ran 9 tests / OK"；当前镜像无 clang-tidy 按设计跳过
4. glm-5.3 独立模型交叉验证：PASS、零发现

剩余动作不变：committer 合入两 PR；Compile 镜像预装 clang-tidy ≥12（@songchangxia）后即真实拦截；合入后关本 issue。

第四轮完成（2026-10-21 中午）

作者三项要求已全部落实，双仓 CI 复跑通过（ci-pipeline-passed）：

• hcomm#4438（e4b9972b9）/ hccl#2494（ce37b166）

1. 增量基线加固：默认基线恒为 upstream/<目标分支>（TARGET_BRANCH 只选分支名），使用前从 gitcode 上游 fetch 刷新；三点 diff 语义文档化——新增行永远指"本分支相对上游最新目标分支的新增"，上游新增行不归属本分支，本地过期分支不可能成为基线
2. 豁免政策：.clang-tidy 注释重写为原则上禁止屏蔽（豁免行与代码同等检视、无理由即拒绝），不再提供可照抄的 NOLINT 样板（机制指向 clang-tidy 官方文档），自测配方用泛化占位写法并注明仅限自测
3. glm-5.3 交叉验证：终审 PASS、发现零——基线语义无回归、豁免政策未触碰、两仓脚本字节一致、单测 12/12（含交叉验证发现的两处修复：提交计数对齐、resolve_base_ref 显式本地带斜杠分支尊重）

剩余动作不变：committer 合入两 PR；Compile 镜像预装 clang-tidy ≥12（@songchangxia）后即真实拦截；合入后关本 issue。

第五轮完成（2026-10-21 下午）

作者两项要求落实完毕，双仓 CI 复跑通过（ci-pipeline-passed）：

• hcomm#4438（3b012c697）/ hccl#2494（feb03521）

1. 基线兜底（任何 remote 命名）：upstream/origin 远程不可用时，脚本从任一 gitcode remote URL 推导仓名（fork/规范/ssh 形态均支持），直接 fetch gitcode 规范仓（cann/<本仓>）到专用 ref——基线恒为 gitcode 上游最新目标分支；网络不可达按设计 WARNING 跳过、永不误拦
2. 自测配方简化：纯 bash build.sh --pkg -j64 两次构建验证拦截与屏蔽（检查自动在构建末尾执行），不再需要单独脚本命令；收尾清理改为 git reset --hard HEAD~2（精确丢弃两条自测提交，交叉验证建议）
3. glm-5.3 交叉验证 PASS：正则四形态实测正确、fetch 兜底机制与无网降级验证、两仓 16/16 单测一致

剩余动作不变：committer 合入两 PR；Compile 镜像预装 clang-tidy ≥12（@songchangxia）；合入后关本 issue。