feat: Switch clang tools from static binaries to wheels

[shenxianpeng]

closes #364

Summary by CodeRabbit

• Documentation

  • Expanded installation guidance with ordered, platform-specific fallbacks; added direct wheel URLs and removed the old static-binaries link; updated license wording to reference the MIT License.

• Chores

  • Installer now uses build-platform detection, robustly validates versions/paths, emits warnings/errors for invalid or empty inputs, and performs per-tool, version-aware sequential installs with clearer logging and outputs.

[coderabbitai]

Walkthrough

Updated README to prefer clang wheels with ordered fallback sequences per OS and adjusted links/licensing wording. Reworked action.yml to validate/coerce version, build a per-tool install list from inputs, and perform tool-by-tool installation choosing between wheel and legacy installers.

Changes

Cohort / File(s)	Change Summary
Documentation README.md	Replaced references to clang-tools-static-binaries with explicit wheel URLs for clang-tidy and clang-format; removed static-binaries link; introduced ordered, OS-specific fallback install sequences (Linux, macOS, Windows); updated license wording to reference the MIT License; minor wording adjustments.
Action manifest / install logic action.yml	Replaced Windows detection with build_os-based check; added robust version handling (empty -> platform-default exit; attempt integer coercion; handle invalid string vs valid path with distinct outcomes); construct dynamic per-tool list from inputs.tidy-checks and inputs.style; replace single installer invocation with per-tool loop selecting clang-tools or clang-tools-wheel based on tool/version rules and invoking installs per-tool with appropriate logging and exit paths.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

• Review action.yml version coercion/error paths and how path-valued version is treated.
• Verify per-tool install selection logic (when to use wheels vs legacy installer) and platform-specific branching.
• Confirm logging, runner invocation, and exit status behavior preserved across the new loop.

Possibly related PRs

• Add clang v20 and change default version to v16 #299 — Overlapping changes to action.yml version handling and validation logic.
• fix: venv usage #314 — Related migration discussions and installer invocation changes between static binaries and wheels.

Suggested reviewers

• shenxianpeng

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title accurately describes the main objective: switching clang tools installation from static binaries to Python wheels, which aligns with the primary changes in both README.md and action.yml.
Linked Issues check	✅ Passed	The PR successfully implements the core objective from issue #364: switching clang tools installation from static-binaries to Python wheels by updating documentation and modifying the installation workflow to use clang-tools-wheel.
Out of Scope Changes check	✅ Passed	All changes in README.md and action.yml are directly scoped to implementing the wheels-based installation approach from issue #364; no unrelated modifications detected.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-364

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b72d11b and 454ad27.

📒 Files selected for processing (2)

• README.md (2 hunks)
• action.yml (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• README.md

🧰 Additional context used

🧠 Learnings (5)

📚 Learning: 2025-08-17T12:34:25.463Z

Learnt from: 2bndy5
Repo: cpp-linter/cpp-linter-action PR: 314
File: action.yml:394-416
Timestamp: 2025-08-17T12:34:25.463Z
Learning: In the cpp-linter-action project, technical improvements can be deferred to separate PRs when they're not critical to the current changes, especially when the current implementation is known to work correctly.

Applied to files:

• action.yml

📚 Learning: 2025-08-17T12:50:57.038Z

Learnt from: 2bndy5
Repo: cpp-linter/cpp-linter-action PR: 314
File: action.yml:273-321
Timestamp: 2025-08-17T12:50:57.038Z
Learning: In Nu shell, `$in` is shorthand for a closure that takes 1 argument, so `(...) | complete | $in.exit_code == 0` is equivalent to `(...) | complete | {|in| $in.exit_code == 0}`.

Applied to files:

• action.yml

📚 Learning: 2025-08-17T12:31:25.319Z

Learnt from: 2bndy5
Repo: cpp-linter/cpp-linter-action PR: 314
File: action.yml:273-321
Timestamp: 2025-08-17T12:31:25.319Z
Learning: In Nu shell, the pattern `(...) | complete | $in.exit_code == 0` is valid syntax for checking command exit codes, where `complete` captures the command result and `$in` refers to the piped input.

Applied to files:

• action.yml

📚 Learning: 2025-08-17T13:20:51.048Z

Learnt from: 2bndy5
Repo: cpp-linter/cpp-linter-action PR: 314
File: README.md:206-211
Timestamp: 2025-08-17T13:20:51.048Z
Learning: For GitHub Actions documentation references in cpp-linter-action, prefer stable workflow syntax documentation links over "canonical" specialized pages that may redirect, as the comprehensive workflow syntax page provides better context and examples for container configuration.

Applied to files:

• action.yml

📚 Learning: 2025-08-17T12:34:25.463Z

Learnt from: 2bndy5
Repo: cpp-linter/cpp-linter-action PR: 314
File: action.yml:394-416
Timestamp: 2025-08-17T12:34:25.463Z
Learning: The cpp-linter/cpp-linter-action repository manages the downstream parsing of command-line arguments through their own cpp-linter/cpp-linter project, so passing empty string values for flags like --extra-arg="" is acceptable and known to work in their implementation.

Applied to files:

• action.yml

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)

• GitHub Check: test (windows-latest, 17)
• GitHub Check: test (windows-latest, 13)
• GitHub Check: test (windows-latest, 12)
• GitHub Check: test (macos-latest, 20)
• GitHub Check: test (macos-latest, 21)
• GitHub Check: test (ubuntu-latest, 21)
• GitHub Check: test (macos-latest, 12)
• GitHub Check: test (macos-latest, 11)

🔇 Additional comments (3)

action.yml (3)

351-351: Platform detection refactored correctly for consistency.

Line 351 now uses (version | get "build_os") | str starts-with "windows" for Windows detection, aligning with the suggestion from past reviews. This approach is more robust than previous alternatives and consistent with the platform check at line 420. Build_os returns values like "windows-x86_64", "macos-aarch64", and "linux-x86_64", making the string prefix check reliable across all GitHub Actions runners.

---

402-428: Per-tool installation with correct version-based fallback logic.

The implementation properly:

• Builds a dynamic tool list (lines 402-410) based on actual usage: clang-tidy is included only if tidy-checks != "-*" (not disabled), and clang-format only if style is not empty
• Iterates per-tool (lines 413-428) to install only what's needed, avoiding unnecessary installations
• Applies version-aware fallback logic (lines 415-426):
  • Clang-tidy < v13: uses clang-tools (static binaries) for compatibility
  • Clang-format ≤ v9 on non-Linux: uses clang-tools (addresses issue Switch clang tools from static binaries to wheels? #364 regarding wheel platform tag availability)
  • All other cases: uses clang-tools-wheel for the modern wheels approach
• Platform detection at line 420 correctly uses (version | get "build_os") | str starts-with "linux" for robust Linux identification

The fallback strategy directly addresses the PR objective to switch to wheels while maintaining backward compatibility for older clang-tidy versions and the wheel availability constraints documented in issue #364.

---

379-395: Based on my research, I found that the pattern let result = try { ... } catch { ... } was explicitly requested as a feature in Nushell issue #10452, but the implementation status remains unclear from the available documentation. While production code from March 2025 uses similar try-catch assignment patterns successfully, I cannot definitively verify the variable scoping behavior you requested since the Nushell interpreter is not available in the sandbox environment.

The code in action.yml (lines 379-395) follows a pattern where:

• On successful try block execution, $version_str | into int result should assign to $result
• On error, the catch block handles it

However, without direct execution capability or explicit Nushell version documentation confirming try-catch expression support, I cannot conclusively verify whether the variable version properly scopes after the try-catch block succeeds.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

Cpp-Linter Report ⚠️

Some files did not pass the configured checks!

clang-format (v16.0.6) reports: 2 file(s) not formatted

• docs/examples/demo/demo.hpp
• docs/examples/demo/demo.cpp

clang-tidy (v16.0.6) reports: 7 concern(s)

• docs/examples/demo/demo.hpp:6:11: warning: [modernize-use-default-member-init]

  use default member initializer for 'useless'

      char* useless;
            ^
                   {"\0"}

• docs/examples/demo/demo.hpp:7:9: warning: [modernize-use-default-member-init]

  use default member initializer for 'numb'

      int numb;
          ^
              {0}

• docs/examples/demo/demo.hpp:11:11: warning: [modernize-use-trailing-return-type]

  use a trailing return type for this function

      void *not_useful(char *str){useless = str;}
      ~~~~~~^
      auto                        -> void *

• docs/examples/demo/demo.cpp:3:10: warning: [modernize-deprecated-headers]

  inclusion of deprecated C++ header 'stdio.h'; consider using 'cstdio' instead

  #include <stdio.h>
           ^~~~~~~~~
           <cstdio>

• docs/examples/demo/demo.cpp:8:5: warning: [modernize-use-trailing-return-type]

  use a trailing return type for this function

  int main(){
  ~~~ ^
  auto       -> int

• docs/examples/demo/demo.cpp:10:13: warning: [readability-braces-around-statements]

  statement should be inside braces

      for (;;) break;
              ^
               {

• docs/examples/demo/demo.cpp:13:5: warning: [cppcoreguidelines-pro-type-vararg]

  do not call c-style vararg functions

      printf("Hello world!\n");
      ^

Have any feedback or feature suggestions? Share it here.

[2bndy5]

I think there's a bug in clang-tools-pip. It does not seem to match v9.0.0. Probably a logical error (>= vs >).

[2bndy5]

I have pushed any changes that I requested.

This is now the least breaking implementation that I can muster.

Also, the README now states the origin of clang tools in order of install attempts.

Caution

This should be tested in test repo before merging.
We have made some significant changes to how version input is used before it is passed to cpp-linter.