Add `sanitizers` check: ASan/UBSan (or Miri) are used

Offen
  • Stimmt etwas nicht?
#10 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
72/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
cmake, python
Bereich
tooling

Rechercherichtung

Start by reading the existing checks in the project validator and the referenced cmake/Sanitizers.cmake implementation. Add a sanitizers check that recognizes AddressSanitizer and UndefinedBehaviorSanitizer in CMake files or CI, warns when only one is found, and fails when neither is found. Done means the check passes when both are enabled in at least one configuration; use the existing check tests to verify its outcomes.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Check

New check sanitizers. Applies to: C/C++, Rust, Go. Python: SKIP.

Ecosystem Passes when Warns when Fails when
C/C++ AddressSanitizer and UndefinedBehaviorSanitizer are used in at least one configuration (CMake files or CI): -fsanitize=address, -fsanitize=undefined, /fsanitize=address, or cmake_template-style ENABLE_SANITIZER_* options only one of the two neither
Rust CI runs cargo miri test, or builds with -Zsanitizer=address neither
Go CI runs go test -race (the race detector, Go's ThreadSanitizer); -asan / -msan are a bonus not run

ThreadSanitizer / MemorySanitizer are reported as a bonus.

Relation to ci-build-types

ci-build-types already requires each OS/toolchain to build with sanitizers, but it accepts any sanitizer (sanitizers_enabled in project_validator/build_configurations.py). This check is about which sanitizers are used. Reuse and extend _SANITIZERS_ENABLED instead of adding a second detector.

Reference

cmake/Sanitizers.cmake, enabled by default for top-level builds in ProjectOptions.cmake; Miri; Go race detector.

Implementation: a @practice (project_validator/ecosystems/__init__.py) over a new rule type in project_validator/rules.py. Each ecosystem profile (project_validator/ecosystems/<name>.py) supplies its rule; rules that differ by build system go on that BuildSystem (e.g. ecosystems/c_cpp/cmake.py, meson.py). Ecosystems without the rule report SKIP. The check's "Applies to" (README, --list --format json) follows from the registry, so it grows as new profiles add the rule.

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.