问题文件树

地址：os-checker.github.io/file-tree 或者 https://os-checker.github.io/{user}/{repo}

按编号顺序介绍

  1. 筛选条件：筛选项前面的数字表示该维度的诊断数量
    • User
    • Repo
    • Target：编译目标；默认为 All-Targets
    • Pkg：默认为空，表示该仓库内的全部 packages
    • Features：默认无（默认启用的 features）
    • Checker：检查工具名称；Cargo 为特殊的虚拟工具，表示其他检查工具出现编译错误
    • Kind：检查类别，比如 Clippy 可以细分成 error 和 warn
  2. 收起文件树：对应于快捷键 ←
    • 打开文件树需使用快捷键 →
    • 收起/打开文件树：<space> （空格键）
  3. 收起筛选区域：对应于快捷键 ↑
    • 打开筛选区域需使用快捷键 ↓
    • 收起/打开筛选区域：<esc> （退出键）
  4. 锁图标：
    • 处于锁住状态：地址栏将显示基于该页面查询条件的链接，可分享给其他人看到当前页面相同的内容
    • 处于解锁状态：地址栏只有默认链接，不携带查询条件相关的参数
  5. 总诊断数量：所有适用于筛选条件的全部诊断数量
  6. 文件树：文件树按照诊断数量降序排列；文件树的根是 pkg，而不是具体的某个目录；前面的数字表示诊断数量
  7. 文件节点：数字表示诊断数量；文件树的节点在大多数情况下是该 pkg Cargo.toml 所在目录的相对路径，但也有一些特殊情况，比如
    • 一个本机的绝对路径：有时诊断发生在该 pkg 之外；
    • (virtual) CheckerName 只适用于 Cargo 的诊断：它表示某个具体的检查工具具有 error 输出；导致 error 输出的原因是复杂的，因为它可能来自检查工具，也可能来自 Cargo 本身（编译问题、网络问题等等）；
    • [semver checks] package 维度的诊断，不对应到任何具体的文件，因此这也是虚拟的文件名
    • Not supported to display yet.：有些检查工具没有良好的解析格式，因此无法结构化呈现在哪个文件上有诊断；比如 lockbud 直接打印 debug 诊断信息进行报告，那么 os-checker 只能统计它报告了一个数量（即使你看到明细中它有自己的统计数字），而且不知道发生在哪个文件上。
  8. 明细栏：按照（我认为的）检查工具的重要程度从左到右排列；右上角标识的数字标识该项的诊断计数；该数字具有颜色标识，红、橙、蓝为（我认为的）从高到低的诊断严重程度；每个明细都有文件位置，因此单击文件树依次处理。一般流程为
    • 首先查看 Cargo 栏发生 error 一行的位置，它表示错误报告；
    • 然后查看其他那些红色和橙色的检查结果，优先处理那些诊断报告；
    • 最后查看蓝色低优先级的检查结果；格式化是最基本的规范，在你的项目中运行 cargo fmt 就可以清除该诊断；如果有些诊断结果无法处理也没有关系...
  9. 诊断明细：只显示当前选择的检查类别的明细