| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix: improve log usability Co-authored-by: m0_50621083<hongyuecheng@huawei.com> # message auto-generated for no-merge-commit merge: !4556 merge CANN-log-evaluation-develop into develop fix: improve log usability Created-by: m0_50621083 Commit-by: m0_50621083 Merged-by: cann-robot Description: # Pull Request ## 描述 本次修改针对 GE 代码中的日志易用性问题进行整改，主要包括： - 修复日志中的英文拼写及语法问题； - 优化日志提示语义和表达； - 补充部分日志中的单位及上下文信息； - 统一部分日志及注释的英文表达； - 优化个别不规范的日志输出方式。 本次修改主要涉及日志和提示文本，不改变核心功能逻辑。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 无关联Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 使用 git diff 对本次修改内容进行检查，确认修改范围均属于日志易用性整改。 2. 使用 git diff --check 检查代码格式，确认不存在 trailing whitespace 等格式问题。 3. 检查日志字符串修改前后的参数及格式化占位符，确认日志参数与原有逻辑保持一致。 4. 确认本次修改主要涉及日志、提示信息及相关文本，不影响原有核心功能逻辑。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 本次为日志易用性专项整改，修改范围涉及多个模块，主要针对现有日志中的拼写、语法、语义表达、单位信息以及日志输出规范进行优化。 相关修改不涉及对外接口变更，不改变现有业务流程及核心功能逻辑。 See merge request: cann/ge!4556 | 2 个月前 | |
【质量加固】补充 const 修饰、参数 const 修饰与 lambda 显式捕获 Co-authored-by: worry<2428405332@qq.com> # message auto-generated for no-merge-commit merge: !4572 merge quality-fix into develop 【质量加固】补充 const 修饰、参数 const 修饰与 lambda 显式捕获 Created-by: m0_63918125 Commit-by: worry Merged-by: cann-robot Description: ## 修改内容 共 16 处代码质量修复，覆盖 3 条编码规范规则，涉及 11 个文件。 ### 规则1：成员函数 const 修饰（8处） - compiler/graph/passes/base_pass.h：6 个只读 getter 添加 const - compiler/graph/partition/base_cluster.h：GetPartitionedCallName() 添加 const - inc/.../graph_fusion_pass.h：GetName() 添加 const ### 规则2：参数 const 修饰（4处） - api/atc/omg.cc：CheckDigitStr/StringToInt 的 string 参数添加 const - compiler/.../te_file_utils.h/.cc：IsFileUsed 的 filePath 参数添加 const - parser/.../acl_graph_parser_util.cc：CheckDigitStr 的 string 参数添加 const ### 规则9：lambda 避免默认捕获模式（4处） - 3 处 call_once 中 [&] → []（静态成员无需捕获） - 1 处 [=] → [runnable]（显式捕获所需变量） See merge request: cann/ge!4572 | 2 个月前 | |
【feat】: Support PCIe Through Co-authored-by: kantao1<kantao1@huawei.com> # message auto-generated for no-merge-commit merge: !4394 merge pcie_through into develop 【feat】: Support PCIe Through Created-by: kantao1 Commit-by: kantao1 Merged-by: cann-robot Description: # Pull Request 接口评审时间：2026/08/06(周四) ## 描述 PCIE Through 是 Ascend NPU 硬件能力，允许 device 端算子通过 PCIE 总线直接访问 host 内存。当前单算子场景可用，但在模型编译场景下，编译期无法确定输入 tensor 的真实的地址范围，导致 tiling 阶段无法选择正确 kernel。 本特性通过编译期能力识别 + TilingContext 注入 + 执行期上下文扩展（动态 shape），解决此问题。 ### 核心设计 **编译阶段（lowering）**： - BuildTilingPcieThroughInput 从 DefaultOpImplSpaceRegistryV2 查询算子是否支持 PCIe Through，同时通过 IsPcieThroughEnabled 检查运行环境（option 开关、芯片能力、设备连接类型），两者均满足时将 pcie_through_flag 初始值设为 true - IsPcieThroughEnabled 结果通过 thread_local static 缓存，每个线程仅计算一次 - BuildTilingCommonInputs 在 input_addrs 可用时，通过 BuildRefTensor 将输入从 StorageShape 升级为包含设备地址的 Tensor，使运行时能通过 GetInputTensor(i)->GetAddr() 获取实际输入地址 **运行时（executor）**： - UpdatePcieThroughFlag 读取 pcie_through_flag，为 false 时直接跳过；为 true 时通过 IsAnyInputInPcieRange 遍历输入地址，检查是否落在 PCIe 地址范围内 - 若存在 PCIe 地址 → flag 保持 true；否则改为 false - GetPcieThroughFlag() 接口供 Tiling 函数和缓存键计算使用 **关键修复**： - fwk_data_idx 恢复后向计算（input_num - kFwkDataOffset），修复 symbol tiling 路径中前向计算导致的 702 行 ASSERT 失败 - GetPcieThroughFlag 改为后向 GetInputNum() - 1，与 pcie_through_flag 作为最后一个输入的布局一致 - TilingForAtomic 补充 BuildTilingPcieThroughInput 调用，保证输入布局一致性 - BuildGeneralTilingCacheKey 简化为直接读 GetPcieThroughFlag()，消除运行时查 space_registry 的版本不一致问题 ## 变更类型 - [x] ✨ 新功能 - [x] 🐛 Bug 修复 ## 关联的Issue <!-- 请在右侧关联对应 Issue --> ## 如何测试 1. 编译 UT：make -C cmake-build-gcov ut_fast_runtime2_test ut_exe_graph ut_register -j$(nproc) 2. 运行 PCIe Through 相关 UT：--gtest_filter='*PcieThrough*' 3. 运行 TilingContextBuilder UT：--gtest_filter='TilingContextBuilderUT.*' 4. 在 PCIe 直通环境上执行模型推理，验证 pcie_through 算子正确识别地址并优化搬运 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签 - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定 ## 其他信息 ### 涉及文件 | 仓库 | 文件 | 改动说明 | |------|------|---------| | ge | runtime/v2/graph_builder/bg_tiling.cc | 新增 IsPcieThroughEnabled、BuildTilingPcieThroughInput；BuildTilingCommonInputs 支持 BuildRefTensor；TilingForAtomic 补充 pcie through 输入 | | ge | runtime/v2/kernel/common_kernel_impl/tiling.cc | 新增 IsAnyInputInPcieRange、UpdatePcieThroughFlag；fwk_data_idx 恢复后向计算；BuildGeneralTilingCacheKey 简化 | | ge | runtime/v2/kernel/common_kernel_impl/tiling.h | 新增 kPcieThroughFlag 枚举项 | | metadef | inc/external/exe_graph/runtime/tiling_context.h | GetPcieThroughFlag 改为后向计算 | | ge | tests/ | 新增 PCIe Through 相关 UT/ST 用例 | See merge request: cann/ge!4394 | 2 个月前 | |
【feat】: Support PCIe Through Co-authored-by: kantao1<kantao1@huawei.com> # message auto-generated for no-merge-commit merge: !4394 merge pcie_through into develop 【feat】: Support PCIe Through Created-by: kantao1 Commit-by: kantao1 Merged-by: cann-robot Description: # Pull Request 接口评审时间：2026/08/06(周四) ## 描述 PCIE Through 是 Ascend NPU 硬件能力，允许 device 端算子通过 PCIE 总线直接访问 host 内存。当前单算子场景可用，但在模型编译场景下，编译期无法确定输入 tensor 的真实的地址范围，导致 tiling 阶段无法选择正确 kernel。 本特性通过编译期能力识别 + TilingContext 注入 + 执行期上下文扩展（动态 shape），解决此问题。 ### 核心设计 **编译阶段（lowering）**： - BuildTilingPcieThroughInput 从 DefaultOpImplSpaceRegistryV2 查询算子是否支持 PCIe Through，同时通过 IsPcieThroughEnabled 检查运行环境（option 开关、芯片能力、设备连接类型），两者均满足时将 pcie_through_flag 初始值设为 true - IsPcieThroughEnabled 结果通过 thread_local static 缓存，每个线程仅计算一次 - BuildTilingCommonInputs 在 input_addrs 可用时，通过 BuildRefTensor 将输入从 StorageShape 升级为包含设备地址的 Tensor，使运行时能通过 GetInputTensor(i)->GetAddr() 获取实际输入地址 **运行时（executor）**： - UpdatePcieThroughFlag 读取 pcie_through_flag，为 false 时直接跳过；为 true 时通过 IsAnyInputInPcieRange 遍历输入地址，检查是否落在 PCIe 地址范围内 - 若存在 PCIe 地址 → flag 保持 true；否则改为 false - GetPcieThroughFlag() 接口供 Tiling 函数和缓存键计算使用 **关键修复**： - fwk_data_idx 恢复后向计算（input_num - kFwkDataOffset），修复 symbol tiling 路径中前向计算导致的 702 行 ASSERT 失败 - GetPcieThroughFlag 改为后向 GetInputNum() - 1，与 pcie_through_flag 作为最后一个输入的布局一致 - TilingForAtomic 补充 BuildTilingPcieThroughInput 调用，保证输入布局一致性 - BuildGeneralTilingCacheKey 简化为直接读 GetPcieThroughFlag()，消除运行时查 space_registry 的版本不一致问题 ## 变更类型 - [x] ✨ 新功能 - [x] 🐛 Bug 修复 ## 关联的Issue <!-- 请在右侧关联对应 Issue --> ## 如何测试 1. 编译 UT：make -C cmake-build-gcov ut_fast_runtime2_test ut_exe_graph ut_register -j$(nproc) 2. 运行 PCIe Through 相关 UT：--gtest_filter='*PcieThrough*' 3. 运行 TilingContextBuilder UT：--gtest_filter='TilingContextBuilderUT.*' 4. 在 PCIe 直通环境上执行模型推理，验证 pcie_through 算子正确识别地址并优化搬运 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签 - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定 ## 其他信息 ### 涉及文件 | 仓库 | 文件 | 改动说明 | |------|------|---------| | ge | runtime/v2/graph_builder/bg_tiling.cc | 新增 IsPcieThroughEnabled、BuildTilingPcieThroughInput；BuildTilingCommonInputs 支持 BuildRefTensor；TilingForAtomic 补充 pcie through 输入 | | ge | runtime/v2/kernel/common_kernel_impl/tiling.cc | 新增 IsAnyInputInPcieRange、UpdatePcieThroughFlag；fwk_data_idx 恢复后向计算；BuildGeneralTilingCacheKey 简化 | | ge | runtime/v2/kernel/common_kernel_impl/tiling.h | 新增 kPcieThroughFlag 枚举项 | | metadef | inc/external/exe_graph/runtime/tiling_context.h | GetPcieThroughFlag 改为后向计算 | | ge | tests/ | 新增 PCIe Through 相关 UT/ST 用例 | See merge request: cann/ge!4394 | 2 个月前 | |
【feat】: Support PCIe Through Co-authored-by: kantao1<kantao1@huawei.com> # message auto-generated for no-merge-commit merge: !4394 merge pcie_through into develop 【feat】: Support PCIe Through Created-by: kantao1 Commit-by: kantao1 Merged-by: cann-robot Description: # Pull Request 接口评审时间：2026/08/06(周四) ## 描述 PCIE Through 是 Ascend NPU 硬件能力，允许 device 端算子通过 PCIE 总线直接访问 host 内存。当前单算子场景可用，但在模型编译场景下，编译期无法确定输入 tensor 的真实的地址范围，导致 tiling 阶段无法选择正确 kernel。 本特性通过编译期能力识别 + TilingContext 注入 + 执行期上下文扩展（动态 shape），解决此问题。 ### 核心设计 **编译阶段（lowering）**： - BuildTilingPcieThroughInput 从 DefaultOpImplSpaceRegistryV2 查询算子是否支持 PCIe Through，同时通过 IsPcieThroughEnabled 检查运行环境（option 开关、芯片能力、设备连接类型），两者均满足时将 pcie_through_flag 初始值设为 true - IsPcieThroughEnabled 结果通过 thread_local static 缓存，每个线程仅计算一次 - BuildTilingCommonInputs 在 input_addrs 可用时，通过 BuildRefTensor 将输入从 StorageShape 升级为包含设备地址的 Tensor，使运行时能通过 GetInputTensor(i)->GetAddr() 获取实际输入地址 **运行时（executor）**： - UpdatePcieThroughFlag 读取 pcie_through_flag，为 false 时直接跳过；为 true 时通过 IsAnyInputInPcieRange 遍历输入地址，检查是否落在 PCIe 地址范围内 - 若存在 PCIe 地址 → flag 保持 true；否则改为 false - GetPcieThroughFlag() 接口供 Tiling 函数和缓存键计算使用 **关键修复**： - fwk_data_idx 恢复后向计算（input_num - kFwkDataOffset），修复 symbol tiling 路径中前向计算导致的 702 行 ASSERT 失败 - GetPcieThroughFlag 改为后向 GetInputNum() - 1，与 pcie_through_flag 作为最后一个输入的布局一致 - TilingForAtomic 补充 BuildTilingPcieThroughInput 调用，保证输入布局一致性 - BuildGeneralTilingCacheKey 简化为直接读 GetPcieThroughFlag()，消除运行时查 space_registry 的版本不一致问题 ## 变更类型 - [x] ✨ 新功能 - [x] 🐛 Bug 修复 ## 关联的Issue <!-- 请在右侧关联对应 Issue --> ## 如何测试 1. 编译 UT：make -C cmake-build-gcov ut_fast_runtime2_test ut_exe_graph ut_register -j$(nproc) 2. 运行 PCIe Through 相关 UT：--gtest_filter='*PcieThrough*' 3. 运行 TilingContextBuilder UT：--gtest_filter='TilingContextBuilderUT.*' 4. 在 PCIe 直通环境上执行模型推理，验证 pcie_through 算子正确识别地址并优化搬运 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签 - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定 ## 其他信息 ### 涉及文件 | 仓库 | 文件 | 改动说明 | |------|------|---------| | ge | runtime/v2/graph_builder/bg_tiling.cc | 新增 IsPcieThroughEnabled、BuildTilingPcieThroughInput；BuildTilingCommonInputs 支持 BuildRefTensor；TilingForAtomic 补充 pcie through 输入 | | ge | runtime/v2/kernel/common_kernel_impl/tiling.cc | 新增 IsAnyInputInPcieRange、UpdatePcieThroughFlag；fwk_data_idx 恢复后向计算；BuildGeneralTilingCacheKey 简化 | | ge | runtime/v2/kernel/common_kernel_impl/tiling.h | 新增 kPcieThroughFlag 枚举项 | | metadef | inc/external/exe_graph/runtime/tiling_context.h | GetPcieThroughFlag 改为后向计算 | | ge | tests/ | 新增 PCIe Through 相关 UT/ST 用例 | See merge request: cann/ge!4394 | 2 个月前 | |
fix: improve log usability Co-authored-by: m0_50621083<hongyuecheng@huawei.com> # message auto-generated for no-merge-commit merge: !4556 merge CANN-log-evaluation-develop into develop fix: improve log usability Created-by: m0_50621083 Commit-by: m0_50621083 Merged-by: cann-robot Description: # Pull Request ## 描述 本次修改针对 GE 代码中的日志易用性问题进行整改，主要包括： - 修复日志中的英文拼写及语法问题； - 优化日志提示语义和表达； - 补充部分日志中的单位及上下文信息； - 统一部分日志及注释的英文表达； - 优化个别不规范的日志输出方式。 本次修改主要涉及日志和提示文本，不改变核心功能逻辑。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 无关联Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 使用 git diff 对本次修改内容进行检查，确认修改范围均属于日志易用性整改。 2. 使用 git diff --check 检查代码格式，确认不存在 trailing whitespace 等格式问题。 3. 检查日志字符串修改前后的参数及格式化占位符，确认日志参数与原有逻辑保持一致。 4. 确认本次修改主要涉及日志、提示信息及相关文本，不影响原有核心功能逻辑。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 本次为日志易用性专项整改，修改范围涉及多个模块，主要针对现有日志中的拼写、语法、语义表达、单位信息以及日志输出规范进行优化。 相关修改不涉及对外接口变更，不改变现有业务流程及核心功能逻辑。 See merge request: cann/ge!4556 | 2 个月前 | |
fix: improve log usability Co-authored-by: m0_50621083<hongyuecheng@huawei.com> # message auto-generated for no-merge-commit merge: !4556 merge CANN-log-evaluation-develop into develop fix: improve log usability Created-by: m0_50621083 Commit-by: m0_50621083 Merged-by: cann-robot Description: # Pull Request ## 描述 本次修改针对 GE 代码中的日志易用性问题进行整改，主要包括： - 修复日志中的英文拼写及语法问题； - 优化日志提示语义和表达； - 补充部分日志中的单位及上下文信息； - 统一部分日志及注释的英文表达； - 优化个别不规范的日志输出方式。 本次修改主要涉及日志和提示文本，不改变核心功能逻辑。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 无关联Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 使用 git diff 对本次修改内容进行检查，确认修改范围均属于日志易用性整改。 2. 使用 git diff --check 检查代码格式，确认不存在 trailing whitespace 等格式问题。 3. 检查日志字符串修改前后的参数及格式化占位符，确认日志参数与原有逻辑保持一致。 4. 确认本次修改主要涉及日志、提示信息及相关文本，不影响原有核心功能逻辑。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 本次为日志易用性专项整改，修改范围涉及多个模块，主要针对现有日志中的拼写、语法、语义表达、单位信息以及日志输出规范进行优化。 相关修改不涉及对外接口变更，不改变现有业务流程及核心功能逻辑。 See merge request: cann/ge!4556 | 2 个月前 | |
fix: improve log usability Co-authored-by: m0_50621083<hongyuecheng@huawei.com> # message auto-generated for no-merge-commit merge: !4556 merge CANN-log-evaluation-develop into develop fix: improve log usability Created-by: m0_50621083 Commit-by: m0_50621083 Merged-by: cann-robot Description: # Pull Request ## 描述 本次修改针对 GE 代码中的日志易用性问题进行整改，主要包括： - 修复日志中的英文拼写及语法问题； - 优化日志提示语义和表达； - 补充部分日志中的单位及上下文信息； - 统一部分日志及注释的英文表达； - 优化个别不规范的日志输出方式。 本次修改主要涉及日志和提示文本，不改变核心功能逻辑。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 无关联Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 使用 git diff 对本次修改内容进行检查，确认修改范围均属于日志易用性整改。 2. 使用 git diff --check 检查代码格式，确认不存在 trailing whitespace 等格式问题。 3. 检查日志字符串修改前后的参数及格式化占位符，确认日志参数与原有逻辑保持一致。 4. 确认本次修改主要涉及日志、提示信息及相关文本，不影响原有核心功能逻辑。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 本次为日志易用性专项整改，修改范围涉及多个模块，主要针对现有日志中的拼写、语法、语义表达、单位信息以及日志输出规范进行优化。 相关修改不涉及对外接口变更，不改变现有业务流程及核心功能逻辑。 See merge request: cann/ge!4556 | 2 个月前 | |
refactor: protobuf生成切换工程函数 Co-authored-by: Feiteng Zheng<zhengfeiteng1@h-partners.com> # message auto-generated for no-merge-commit merge: !4502 merge 20260821-switch-cmake-protobuf-generate into develop refactor: protobuf生成切换工程函数 Created-by: zhengfeiteng Commit-by: Feiteng Zheng Merged-by: cann-robot Description: # Pull Request ## 描述 protobuf生成切换工程函数。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 2. ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/ge!4502 | 2 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 个月前 |