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

Aberta
  • Algo errado?
#10 3 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
72/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
cmake, python
Domínio
tooling

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Python
Estrelas
4
Forks
1
Merge médio
10h 41min
PRs com merge (30d)
79

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de cpp-best-practices/project_validator

Todas as issues de cpp-best-practices/project_validator

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.