You can't get SonarQube results locally (just saying, doesn't mean we don't want it). You can for other tools like e.g. clang-tidy, which is quite easy to do actually (and which I tried already) since meson has built-in support for it.

I suppose that any SAS-type web platform (such as Sonar Qubes) would not be particularly well suited to the project.

Perhaps something like Clang-tidy + Infer would do the job?
(If it's not already in place, I'm not familiar with what currently exists.)

Proposed Next Steps

Thanks @ComputerCraftr for testing clang-tidy locally. Based on the discussion so far, here's a proposal to move this forward:

What's In Scope

• clang-tidy with a conservative initial configuration
• Local analysis scripts that developers can run easily
• CI integration that blocks on new issues (not existing ones)
• Test coverage tracking (Codecov or similar). CODECOV is free to use with GitHub for open source projects. A badge can be added to the project README, with 80% being recommended as a good target.

What's Out of Scope (for now)

• SonarQube or other SaaS platforms (as discussed, not a good fit for this project)
• Addressing all 1000+ existing warnings immediately
• Advanced or experimental analyzers

Handling the 1000 Warnings

I'd suggest we take an incremental approach:

1. Start with a minimal clang-tidy config that catches only high-confidence issues
2. Create a baseline to suppress existing warnings
3. Configure CI to fail only on new issues introduced in PRs
4. Address legacy warnings incrementally over time

Conservative clang-tidy Configuration

Here's a starting point that focuses on likely bugs while avoiding noisy or stylistic checks:

Checks: >
  clang-analyzer-core.*,
  clang-analyzer-deadcode.*,
  clang-analyzer-security.*,
  clang-analyzer-unix.*,
  bugprone-*,
  -bugprone-easily-swappable-parameters,
  -bugprone-implicit-widening-of-multiplication-result,
  performance-*,
  -performance-avoid-endl,
  readability-braces-around-statements,
  readability-redundant-control-flow,
  -clang-analyzer-optin.*

HeaderFilterRegex: '.*'
WarningsAsErrors: ''

This config focuses on:

• Core static analysis checks (null dereferences, memory issues)
• Security issues
• Likely bugs (bugprone-*)
• Performance issues with high confidence

Action Items

1. @ComputerCraftr or @mikedld: Would one of you be willing to submit a PR with:

   • The conservative config above (or similar)
   • A simple script to run clang-tidy locally
   • Documentation in CONTRIBUTING.md

2. Baseline approach: We can use --export-fixes to generate a baseline, or just start fresh and ignore existing warnings initially

3. CI integration: Once we agree on the config, integrate it into CI to run on new code only

Does this approach make sense? Would it be good to break this out into separate issues?

Related: #18