Validation

Référence actuelle

Plan 11 step 1, 2026-10-03, commit b1a471f, Windows x64 : clang-cl 23.1.2, SDK LLVM 23.1.2 (/MT, _ITERATOR_DEBUG_LEVEL=0), Lizard 1.24.0, clang-tidy 22.1.8, version OTP épinglée 21776803ecd1 avec OTP oracle 29.1.1 / ERTS 17.1.

Exécuter la porte de validation

Depuis un shell développeur Visual Studio x64 avec C:\Program Files\LLVM\bin dans le PATH (la sélection automatique du SDK réutilise thirdparty/) :

cmake --preset debug --fresh -DBUILD_TESTING=ON -G Ninja -DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl
cmake --build build/debug
ctest --preset debug-fast                  # during development
ctest --preset debug -j 16                 # full mode, at feature completion
cmake --build build/debug --target check-quality      # changed files + dependents
cmake --build build/debug --target check-quality-all  # whole tree

• CLAUSE_TEST_MODE=fast exécute les corpus de référence en O0 positionnel plus en projet O2 sans spécialisation, exécute les mutations une seule fois et ignore les tests full_only. Le mode complet (par défaut) exécute toutes les combinaisons de pilote et de politique.
• check-quality, make format et make-format.bat couvrent les fichiers modifiés depuis HEAD ainsi que les fichiers non suivis ; cmake/quality_scope.py ajoute les unités de traduction qui incluent un en-tête modifié. Toute modification de .clang-tidy, de cmake/ ou du CMake de production sélectionne l'ensemble.
• Les programmes de test ne portent aucune information de débogage (pas de PDB) ; configurer avec -DCLAUSE_TEST_DEBUG_INFO=ON pour les reconstruire en vue d'un débogueur. Les consommateurs natifs imbriqués lient le runtime du build parent via ClauseRuntimeTargets.cmake au lieu de le recompiler ; seul runtime_link construit le runtime de manière autonome.
• Les seuils et les suppressions ne sont jamais relevés pour franchir la porte.

Fixtures et provenance

• Les builds et les tests normaux n'ont besoin ni d'OTP ni de son dépôt source. Les résultats de référence (goldens) ont été générés une fois à partir d'OTP et sont versionnés avec leurs empreintes ; les vérifications d'empreinte s'exécutent avant toute utilisation d'une fixture.
• Dix-neuf corpus de motifs et de guards contiennent 67 748 valeurs ou erreurs natives attendues et 106 lignes d'acceptation sémantique. Chaque corpus natif exécute les pilotes positionnel et projet en O0/O2, avec et sans spécialisation, en appels locaux et distants.
• Les entrées Erlang versionnées sont écrites localement (tests/fixtures/patternmatch/fragments/, préprocesseur semantic/headers/). Un audit du 2026-10-03 a supprimé tous les fichiers OTP copiés ; une comparaison par fenêtres de 60 jetons avec 4 150 fichiers Erlang et 1 190 fichiers C/C++ d'OTP n'a trouvé aucun recouvrement restant hormis un tuple d'entiers généré. fixture_sources impose cette isolation.
• Six fixtures de programmes cibles (tests/fixtures/programs/, plan 11 step 2) contiennent les références OTP de sortie standard et de code de sortie ainsi que les diagnostics de compilation actuels ; programs_compile les vérifie sans OTP et tests/compiler/programs/regenerate.py --check les reproduit sous OTP (carte des fixtures).
• Les références d'affichage des termes (tests/fixtures/printing/, plan 11 step 4) contiennent le texte OTP de ~w et de erlang:display/1 pour 9 542 valeurs ainsi que la sortie standard OTP des appels d'affichage compilés ; tests/compiler/printing/regenerate.py --check les reproduit (notes sur les fixtures).
• Les cas de référence des exécutables (tests/fixtures/executables/, plan 11 step 8) sont des répertoires source accompagnés d'un golden.json contenant la sortie standard et le code de sortie OTP ainsi qu'un motif de sortie d'erreur rédigé à la main ; tests/compiler/executables/run.py lie et exécute chaque cas selon la matrice politique/pilote (CTest executables_<case>), et regenerate.py --check les reproduit sous OTP (notes sur les cas).
• La régénération et les audits en direct sont explicites : -DCLAUSE_OTP_AUDITS=ON et tests/compiler/patternmatch/regenerate.py (instructions). Rien ne rafraîchit silencieusement les références ni la version épinglée.

Conception des tests

Le comportement est testé via la vraie CLI, les objets émis, des consommateurs natifs liés et les références OTP. Des tests unitaires ciblés ne subsistent que là où le code source ne peut pas atteindre l'état voulu, chacun avec son objectif indiqué dans le test :

• Budgets injectés et défaillances d'allocation ou d'E/S (project_limits, project_creation_failure, codegen_limits, codegen_write_failure, runtime_lifecycle_failure, points d'injection de défaillances des appels générés).
• Invariants de propriété privée, de handles invalides ou périmés et d'annulation dans l'analyseur syntaxique, le graphe de types sémantique et le backend.
• Validation des mots bruts et limites des termes 32/64 bits (runtime_immediate, runtime_term_tag, abi_integers).
• Défaillances du récepteur de diagnostics et instantané des identifiants de fonctionnalités stables.

Les cas liés aux capacités du système de fichiers (liens, alias de casse) signalent des tests ignorés au cas par cas ; ils ne remplacent jamais la réussite d'un test complet.

État des plateformes et des sanitizers

• Exécution native du code généré : Windows x64 uniquement.
• Linux, Apple Silicon et exécution native 32 bits : en attente (les objets sont seulement inspectés).
• ASan, UBSan et LeakSanitizer pour le compilateur et le frontend : en attente. Le SDK LLVM précompilé pour Windows entre en conflit avec le code instrumenté (annotate_string 0 contre 1 ; auparavant aussi des symboles d'allocateur rpmalloc/ASan en double). Aucune vérification n'a été désactivée pour le contourner.
• ASan limité au runtime réussit sous Windows avec des sondes Release, /EHsc /fsanitize=address, /MT, la bibliothèque d'importation ASan de Clang et le thunk du runtime statique, et la DLL ASan dans le PATH.
• Des exécutions historiques sur macOS arm64 (2026-09-19/20) ont réussi les builds Debug complet, C++26, ASan+UBSan, compilateur seul et runtime seul pour les étapes de l'analyseur syntaxique et des projets ; elles sont antérieures au backend.

Historique

Condensé à partir des anciens comptes rendus par étape (originaux dans l'historique Git jusqu'au commit 2777c98). Sauf mention contraire : Windows x64, LLVM 23.1.2, version épinglée 21776803ecd1, OTP oracle 29.1.1 / ERTS 17.1. Les nombres de tests correspondent à des passes CTest complètes sans aucun test ignoré.

PG = étape du plan motifs/guards (archivé dans .agents/00-finished.md).