Validering

Nuvarande baslinje

Senast registrerade grindresultat på Windows x64-utvecklingsvärden (clang-cl och LLVM SDK 23.1.2, /MT, _ITERATOR_DEBUG_LEVEL=0); senare steg registrerar sina i .agents/00-finished.md:

Köra grinden

Från ett x64-utvecklarskal för Visual Studio med C:\Program Files\LLVM\bin i PATH (automatiskt val av SDK återanvänder 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, one unit per header
cmake --build build/debug --target check-quality-all  # whole tree

• CLAUSE_TEST_MODE=fast kör golden-korpusar med O0 positional plus O2 specialization-off project, kör mutationer en gång och hoppar över full_only-tester (separata konsumentprojekt som runtime_generated_link, mätningar, värd-OTP-granskningen library_freshness och de långsamma arbetsflödena linking_lto, linking_exports, linking_compile_cache, programs_compile och transforms_cache). Fullständigt läge (standard) kör alla kombinationer av drivrutin och policy.
• Långa tester som drivs av ett Python- eller CMake-skript har en fast CTest-COST: CTest lär sig ett omslags kostnad från dess egen lilla CPU-tid och skulle starta dem sist.
• Belastningskänsliga tester (CLAUSE_LOAD_SENSITIVE_TESTS i den översta CMakeLists.txt: frontend_cli, codegen_examples, linking_debugger, executables_applications) fick bara timeout eller förlorade tidsberoende kapplöpningar vid en fullständig parallell körning. De har DEPENDS på alla andra tester, så de startar när resten av urvalet är färdigt och har processorerna för sig själva; ett misslyckat beroende gör inte att de hoppas över.
• CLAUSE_TEST_TIMEOUT_SCALE=N multiplicerar gränserna per körning för golden-köraren (60 s) och köraren för semantiska fall (15 s) för instrumenterade byggen.
• check-quality, make format och make-format.bat täcker filer ändrade sedan HEAD plus ospårade filer; cmake/quality_scope.py lägger för varje ändrad header till en översättningsenhet som inkluderar den (dess egen källfil, annars dess första användare, från Ninjas beroendedata för valfri konfiguration; headerns övriga beroende enheter lämnas till check-quality-all i den fullständiga kontrollen) och, för clang-tidy, enheter vars kompileringskommando skiljer sig från det som den senaste godkända körningen registrerade (build/debug/quality/tidy-commands.json), så att en ändrad byggregel bara kontrollerar de enheter den ändrar igen. Ändringar av .clang-tidy eller tidy-skripten väljer allt, liksom ändrade byggregler före den första registrerade körningen.
• CLAUSE_OPTIMIZED_COMPILER (standard ON) kompilerar clau och kompilatorbiblioteken optimerade även i Debug-byggen, med bibehållen felsökningsinformation och Debug-budgetarna för inferens; testerna tillbringar det mesta av sin tid i clau. När en kompilatorkrasch behöver stegas igenom, konfigurera med -DCLAUSE_OPTIMIZED_COMPILER=OFF, bygg om och kör det misslyckade testet igen.
• Testprogram har ingen felsökningsinformation (inga PDB:er); konfigurera med -DCLAUSE_TEST_DEBUG_INFO=ON för att bygga om dem för en debugger. Nästlade native-konsumenter länkar föräldrabyggets runtime via ClauseRuntimeTargets.cmake i stället för att kompilera den igen; endast runtime_link bygger runtime fristående.
• Tröskelvärden och undertryckningar höjs aldrig för att klara grinden. Två undantag för tredjepartskod är konfigurerade (användarens beslut): cmake/tidy_filter.py tar bort rapporter från den statiska analysatorn som ligger i Boost-headers (falska positiva för limb-lagring i Boost.Multiprecision på Linux som en omskrivning av den anropande koden bara flyttar) och räknar dem i utdata, och bugprone-exception-escape ignorerar bad_array_new_length (MSVC:s flyttkonstruktorer för map/set allokerar; ett allokeringsfel är ändå fatalt).
• clang-tidy kontrollerar projektets headers på varje värd: headerfiltret godtar avgränsarna / och \.

Linux

Samma grind körs på Linux med det fastlåsta LLVM 23.1.2 SDK för Linux som värdkompilator (CC/CXX från dess bin/), systemets libstdc++, Ninja och CMake 3.28 eller nyare. Boost 1.90 och toml++ 3.4.0 kommer från installerade paket eller extraheras till thirdparty/ (boost_1_90_0/, tomlplusplus-3.4.0/); endast Windows laddar ned dem. Versionsarkivets ld.lld länkar ICU 70 (Ubuntu 22.04) och dess lldb länkar Python 3.14; på värdar utan dem behöver linking_lto ICU 70 i LD_LIBRARY_PATH, och linking_debugger använder GDB.

cmake --preset debug --fresh -G Ninja -DBUILD_TESTING=ON
cmake --build build/debug
ctest --preset debug -j 16

check-quality (Lizard, clang-tidy) körs endast på Windows-värden för utveckling; andra värdar bygger och kör testerna (den var ren på Linux en gång, se historik).

Andra mål

32-bitars- och ARM-mål kontrolleras utan en kompilator byggd för dem (inget LLVM SDK finns för de värdarna):

• Ett bygge med endast runtime (-DCLAUSE_BUILD_COMPILER=OFF -DBUILD_TESTING=ON) för målet kör runtime- och ABI-testerna där: inbyggt, i ett användarland för målet (chroot) eller genom värdens emulator (qemu binfmt).
• tests/compiler/executables/cross.py kör varje golden för körbara filer och varje programfixtur med den här värdens clau, --target-triple, det byggets runtime-arkiv och en --linker som når målets bibliotek (run.py --target-option skickar dem vidare).

Fixturer och ursprung

• Normala byggen och tester behöver varken OTP eller dess källkodsutcheckning. Goldens genererades en gång från OTP och är incheckade med hashar; hashkontroller körs innan någon fixtur används.
• Nitton mönster-/guard-korpusar innehåller 67 748 förväntade native-värden/fel och 106 rader för semantisk acceptans. Varje native-korpus kör positionella drivrutiner och projektdrivrutiner vid O0/O2 med specialisering på/av, lokala och fjärranrop.
• Incheckade Erlang-indata är skrivna lokalt (tests/fixtures/patternmatch/fragments/, preprocessorns semantic/headers/); fixture_sources upprätthåller isoleringen från OTP:s källkod.
• Sex programfixturer för slutmålet (tests/fixtures/programs/) innehåller goldens för stdout/slutstatus från OTP och deras kompileringsdiagnostik; programs_compile kontrollerar dem utan OTP och tests/compiler/programs/regenerate.py --check återskapar dem under OTP (fixturkarta).
• Goldens för termutskrift (tests/fixtures/printing/) innehåller OTP:s ~w- och erlang:display/1-text för 9 542 värden plus OTP:s stdout från kompilerade display-anrop; tests/compiler/printing/regenerate.py --check återskapar dem (fixturanteckningar).
• Golden-fall för körbara filer (tests/fixtures/executables/) är källkataloger plus en golden.json med stdout/slutstatus från OTP och ett handskrivet stderr-mönster; tests/compiler/executables/run.py länkar och kör vart och ett under matrisen av policyer/drivrutiner (CTest executables_<case>), och regenerate.py --check återskapar dem under OTP (fallanteckningar).
• Regenerering och levande granskningar är explicita: -DCLAUSE_OTP_AUDITS=ON och tests/compiler/patternmatch/regenerate.py (instruktioner). Ingenting uppdaterar goldens eller pinnen i tysthet.

Testdesign

Beteende testas via den riktiga CLI:n, emitterade objekt, länkade native-konsumenter och goldens från OTP. Fokuserade enhetstester finns kvar endast där källkod inte kan nå tillståndet, var och ett med sitt syfte angivet i testet:

• Injicerade budgetar och allokerings-/I/O-fel (project_limits, project_creation_failure, codegen_limits, codegen_write_failure, runtime_lifecycle_failure, felsömmar i genererade anrop).
• Privat ägarskap, ogiltiga/inaktuella handtag och invarianter för återställning i parsern, den semantiska typgrafen och backend.
• Validering av råa ord och termgränser för 32/64 bitar (runtime_immediate, runtime_term_tag, abi_integers).
• Fel i diagnostikmottagare och den stabila ögonblicksbilden av funktions-ID:n.

Fall som beror på filsystemets förmågor (länkar, skiftlägesalias) rapporterar överhoppningar per fall; de ersätter aldrig ett godkänt helt test.

Plattforms- och sanitizer-status

• Native-exekvering av genererad kod: Windows x64; Linux x86-64. Resultat för 32-bitars och ARM (runtime-tester och korslänkade goldens) finns i historiken.
• Apple Silicon: inte validerat sedan backend tillkom.
• ASan, UBSan och LeakSanitizer för kompilatorn och runtime: Linux x86-64, en kombinerad Debug-konfiguration (-fsanitize=address,undefined -fno-sanitize=vptr -fno-sanitize-recover=undefined), fullständig CTest med CLAUSE_TEST_TIMEOUT_SCALE=10 (instrumenterad kod körs flera gånger långsammare): ingen sanitizer-rapport. Kompilatorn, runtimen och testprogrammen är instrumenterade; program som clau länkar tar sanitizer-runtimen från ett clang++-omslag i PATH, deras genererade kod är inte instrumenterad. De fyra testerna med injicerad vägran från värden (codegen_failure_*, runtime_lifecycle_failure, runtime_memory) ligger utanför ASan:s räckvidd: dess operator new avbryter vid en omöjlig storlek i stället för att kasta.
• ThreadSanitizer: Linux x86-64, samma instrumenteringsräckvidd med -fsanitize=thread; fullständig CTest och samtidighetstesterna fem gånger vardera rapporterar ingen kapplöpning. Också utanför räckvidden: de två tester som ersätter operator new.
• På Windows står det förbyggda LLVM SDK fortfarande i konflikt med instrumenterad kod (annotate_string 0 mot 1).
• ASan enbart för runtime godkänns på Windows med Release-sonder, /EHsc /fsanitize=address, /MT, Clangs ASan-importbibliotek och statiska runtime-thunk samt ASan-DLL:en i PATH.
• Historiska körningar på macOS arm64 (2026-09-19/20) klarade fullständiga Debug-, C++26-, ASan+UBSan-, enbart kompilator- och enbart runtime-byggen för parser- och projektstegen; de är äldre än backend.

Prestandamätningar

Manuell prestandajämförelse med Erlang/OTP. Den är aldrig en del av CTest, commit-grinden eller check-quality, och endast den behöver ett Erlang/OTP på värden; resultaten är värdspecifika belägg, inte grindresultat.

make-benchmark.bat                         # Windows; set JOBS=N to cap parallel builds
make-benchmark.bat --repeat 9 --only bench_gc,bench_msg
make-benchmark.bat --cpus all                 # unpinned set; default --cpus performance
make benchmark BENCH_ARGS="--baseline HEAD~5"   # other hosts

• Båda konfigurerar och bygger en Release-clau och runtime i build/bench och kör sedan benchmarks/run.py (--help listar dess alternativ).
• Program: benchmarks/bench_*.erl med bench_util.erl, byggda oförändrade av erlc och clau -O2. Var och en tar tid på sina kärnor med erlang:monotonic_time/1 efter ett uppvärmningsanrop och skriver ut BENCH <name> <nanoseconds>: generering av data, bearbetning av data, skräpsamling, meddelandeöverföring, fil-I/O (i en tom temporär arbetskatalog under build/bench/runs, inne i arkivet så att ett antivirusundantag för arkivet täcker den), loopback-socketar och bibliotek (libraries.qlc: qlc_pt-transformeringar av frågor och moduler utformade som fall i qlc_SUITE, tidtagna tillsammans). Iterationsantalen gör att varje kärna varar 1–2 s på OTP, så att timerupplösning och störningar från värden förblir små i förhållande till den; socketkärnor ökar arbetet per anslutning, inte antalet socketar. Utanför tidtagningen väntar uppvärmningen och de tidtagna anropen var för sig tills processerna de startade har avslutats (processes_left-fel efter 10 s). Varje kärna körs i en egen ny process, som avslutas innan nästa kärna startar, så att ingen kärna betalar för heapar som en tidigare kärna förstorat.
• Varje programkörning har ett eget Windows-jobbobjekt eller en egen POSIX-session; nästa körning startar när alla dess processer är borta, och kvarvarande processer som fortfarande lever 30 s efter avslut dödas och rapporteras som ett fel.
• CPU:er: varje process i en körning, både OTP:s och Clauses, körs på uppsättningen --cpus: performance (standard: kärnorna med högst Windows EfficiencyClass, Linux /sys/devices/cpu_core/cpus eller störst cpu_capacity, alltså P-kärnorna på en hybridprocessor och annars alla CPU:er), all, en lista som 0-15 eller 2,4,6, eller en hexmask som 0x5554. På Windows bär körningens jobbobjekt affinitetsgränsen innan programmet återupptas, på Linux sätter programmet den före exec; macOS kan inte binda och kör obundet. Både OTP och Clause startar en aktiv schemaläggare per CPU i uppsättningen, obunden till enskilda CPU:er. Rapporthuvudet och varje historikpost (cpus) anger uppsättningen; kvoter för körningar på olika uppsättningar är inte jämförbara.
• System, på samma värd i en körning, varvade: OTP med sin standardvariant (JIT), OTP -emu_flavor emu när den är installerad (Windows-installeraren levererar endast JIT, så de kolumnerna visar n/a), Clause HEAD vid O2 och med --lto, samt en tidigare Clause-commit (standard: den nyaste commit som är minst en dag äldre än HEAD; --baseline REV, --no-baseline) byggd i ett cachat arbetsträd under build/bench-base/<hash> som delar thirdparty/.
• Rapport: per kärna medianen av --repeat körningar (standard 3) i millisekunder med sex decimaler och dess spridning, förändringen för Clause O2 mot varje system (+N%: Clause snabbare, det andra tar N % längre tid; -N%: Clause tar N % längre tid; (Fx) tidskvoten) med ett geometriskt medelvärde, --lto mot OTP och O2, programmens totala tider inklusive uppstart, körbara filers storlekar, fel och tidsgränser (--timeout, 600 s per körning). En standardkörning mäter i ungefär 15 minuter.
• Körbara filers storlekar i byte: varje program vid -O2, med --lto och vid -O0 (ett extra bygge som bara mäts, aldrig körs; båda hoppas över av --no-lto) och baslinjen vid -O2, med en totalrad och ändringarna O2 mot O0, --lto mot O2, --lto mot O0 och O2 mot baslinjen (-N% mindre); samt clau vid HEAD och baslinjen. Historiken behåller dem som sizes_bytes (programs: program → kolumn → byte, clau: head/baseline → byte; null där ett bygge misslyckades).
• Historik: benchmarks/history/<host>.json behåller en post per kördag (kördatum, HEAD-hash och commitdatum, medianer för Clause, OTP och baslinjen, storlekar samt Clauses tidskvoter otp_ratio och baseline.ratio per kärna), benchmarks/history/reports/<host>/<day>-<hash>.txt textrapporterna; en ny körning samma dag ersätter båda. Poster och rapporter som körts mer än 183 dagar före den nyaste rensas bort; en körning med ändringar i källkoden som inte har checkats in rapporteras men registreras inte. Rapportens historiktabeller visar kvoterna för de senaste 8 kördagarna, vilka förblir jämförbara när kärnornas arbete ändras; poster från före omskalningen till 1–2 s behåller endast sina kvoter. Historikkatalogen ignoreras av git: den stannar på värden som körde den.
• Listningar: med --listings skriver en körning, före mätningen, varje programs --print-asm- och --print-ir-listningar (med bench_util, --entry <program> så att onåbar bibliotekskod utelämnas som i den körbara filen) bredvid rapporterna som <program>.debug.asm / <program>.debug.ll (-O0) och <program>.release.asm / <program>.release.ll (-O2, koden som kolumnen clause-o2 kör), och ersätter den föregående körningens listningar, även med --no-history och ändringar som inte har checkats in. --print-ir är IR före LLVM-kedjan; assemblerkommentarerna citerar IR efter den. Ett program som inte går att kompilera förlorar sina inaktuella listningar.

Historik

Sammanfattat från de tidigare posterna per steg (original i Git-historiken fram till commit 2777c98). Om inget annat anges: Windows x64, LLVM 23.1.2, pin 21776803ecd1, orakel OTP 29.1.1 / ERTS 17.1. Testantal är fullständiga CTest-körningar utan överhoppningar.

PG = steg i mönster-/guard-planen; posterna för plan 11-stegen är arkiverade i .agents/00-finished.md.