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

Ouverte
  • Quelque chose ne va pas ?
#10 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
72/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
cmake, python
Domaine
tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Python
Étoiles
4
Forks
1
Merge moyen
10 h 41 min
PR mergées (30 j)
79

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cpp-best-practices/project_validator

Toutes les issues de cpp-best-practices/project_validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.