Validierung

Aktuelle Basislinie

Plan 11 step 1, 2026-10-03, Commit b1a471f, Windows x64: clang-cl 23.1.2, LLVM SDK 23.1.2 (/MT, _ITERATOR_DEBUG_LEVEL=0), Lizard 1.24.0, clang-tidy 22.1.8, OTP-Pin 21776803ecd1 mit Orakel OTP 29.1.1 / ERTS 17.1.

Ausführen der Prüfstufe

Aus einer x64-Entwickler-Shell von Visual Studio mit C:\Program Files\LLVM\bin im PATH (die automatische SDK-Auswahl verwendet thirdparty/ wieder):

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 führt Golden-Korpora bei O0 positionell plus O2 als Projekt ohne Spezialisierung aus, führt Mutationen einmal aus und überspringt full_only-Tests. Der Vollmodus (Standard) führt alle Treiber-/Richtlinienkombinationen aus.
• check-quality, make format und make-format.bat erfassen die seit HEAD geänderten Dateien plus nicht versionierte Dateien; cmake/quality_scope.py fügt Übersetzungseinheiten hinzu, die einen geänderten Header einbinden. Änderungen an .clang-tidy, cmake/ oder am Produktions-CMake wählen alles aus.
• Testprogramme enthalten keine Debuginformationen (keine PDBs); mit -DCLAUSE_TEST_DEBUG_INFO=ON konfigurieren, um sie für einen Debugger neu zu bauen. Verschachtelte native Konsumenten linken die Runtime des übergeordneten Builds über ClauseRuntimeTargets.cmake, statt sie erneut zu kompilieren; nur runtime_link baut die Runtime eigenständig.
• Schwellenwerte und Unterdrückungen werden nie angehoben, um die Prüfstufe zu bestehen.

Fixtures und Herkunft

• Normale Builds und Tests brauchen weder OTP noch seinen Quelltext-Checkout. Goldens wurden einmalig aus OTP erzeugt und sind mit Hashes eingecheckt; Hash-Prüfungen laufen, bevor ein Fixture verwendet wird.
• Neunzehn Muster-/Guard-Korpora enthalten 67.748 native erwartete Werte/Fehler und 106 semantische Akzeptanzzeilen. Jeder native Korpus führt positionelle und Projekttreiber bei O0/O2 mit Spezialisierung an/aus, lokale und Remote-Aufrufe aus.
• Eingecheckte Erlang-Eingaben sind lokal verfasst (tests/fixtures/patternmatch/fragments/, Präprozessor semantic/headers/). Ein Audit vom 2026-10-03 entfernte alle kopierten OTP-Dateien; ein Vergleich mit einem 60-Token-Fenster gegen 4.150 Erlang-Dateien und 1.190 C/C++-Dateien von OTP fand außer einem erzeugten Ganzzahltupel keine verbleibende Überschneidung. fixture_sources erzwingt die Isolation.
• Sechs Programm-Fixtures für das Endziel (tests/fixtures/programs/, plan 11 step 2) enthalten OTP-Goldens für stdout/Exit-Status und die heutigen Kompilierdiagnosen; programs_compile prüft sie ohne OTP, und tests/compiler/programs/regenerate.py --check reproduziert sie unter OTP (Fixture-Übersicht).
• Goldens zur Termausgabe (tests/fixtures/printing/, plan 11 step 4) enthalten OTP-Text von ~w und erlang:display/1 für 9.542 Werte plus die OTP-stdout kompilierter display-Aufrufe; tests/compiler/printing/regenerate.py --check reproduziert sie (Fixture-Notizen).
• Golden-Fälle für ausführbare Dateien (tests/fixtures/executables/, plan 11 step 8) sind Quelltextverzeichnisse plus eine golden.json mit OTP-stdout/ Exit-Status und einem selbst verfassten stderr-Muster; tests/compiler/executables/run.py linkt und führt jeden unter der Richtlinien-/Treibermatrix aus (CTest executables_<case>), und regenerate.py --check reproduziert sie unter OTP (Fallnotizen).
• Regenerierung und Live-Audits sind explizit: -DCLAUSE_OTP_AUDITS=ON und tests/compiler/patternmatch/regenerate.py (Anleitung). Nichts aktualisiert Goldens oder den Pin stillschweigend.

Testdesign

Verhalten wird über die echte CLI, erzeugte Objekte, gelinkte native Konsumenten und OTP-Goldens getestet. Gezielte Unit-Tests bleiben nur dort, wo Quelltext den Zustand nicht erreichen kann, jeweils mit im Test angegebenem Zweck:

• Eingespeiste Budgets und Allokations-/IO-Fehler (project_limits, project_creation_failure, codegen_limits, codegen_write_failure, runtime_lifecycle_failure, Fehlernähte erzeugter Aufrufe).
• Invarianten zu privatem Besitz, ungültigen/veralteten Handles und Rollback im Parser, im semantischen Typgraphen und im Backend.
• Validierung roher Wörter und 32/64-Bit-Termgrenzen (runtime_immediate, runtime_term_tag, abi_integers).
• Fehlschläge der Diagnosesenke und der stabile Snapshot der Feature-IDs.

Fälle zu Dateisystemfähigkeiten (Links, Groß-/Kleinschreibungs-Aliase) melden Auslassungen pro Fall; sie stehen nie für das Bestehen eines ganzen Tests.

Plattform- und Sanitizer-Status

• Native Ausführung erzeugten Codes: nur Windows x64.
• Linux, Apple Silicon und native 32-Bit-Ausführung: ausstehend (Objekte werden nur untersucht).
• ASan, UBSan und LeakSanitizer für Compiler/Frontend: ausstehend. Das vorgebaute Windows-LLVM-SDK kollidiert mit instrumentiertem Code (annotate_string 0 gegenüber 1; früher auch doppelte rpmalloc-/ASan-Allokatorsymbole). Keine Prüfung wurde deaktiviert, um das zu umgehen.
• ASan nur für die Runtime besteht unter Windows mit Release-Proben, /EHsc /fsanitize=address, /MT, Clangs ASan-Importbibliothek und statischem Runtime-Thunk sowie der ASan-DLL im PATH.
• Historische macOS-arm64-Läufe (2026-09-19/20) bestanden vollständige Debug-, C++26-, ASan+UBSan-, Nur-Compiler- und Nur-Runtime-Builds für die Parser- und Projektstufen; sie liegen vor dem Backend.

Verlauf

Verdichtet aus den früheren schrittweisen Aufzeichnungen (Originale in der Git-Historie bis Commit 2777c98). Sofern nicht anders angegeben: Windows x64, LLVM 23.1.2, Pin 21776803ecd1, Orakel OTP 29.1.1 / ERTS 17.1. Testzahlen sind vollständige CTest-Durchläufe ohne Auslassungen.

PG = Schritt des Muster-/Guard-Plans (archiviert in .agents/00-finished.md).