Валідація

Поточний базовий рівень

Plan 11 step 1, 2026-10-03, коміт 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 21776803ecd1 з еталонним OTP 29.1.1 / ERTS 17.1.

Запуск перевірки

З командного рядка розробника Visual Studio x64 з C:\Program Files\LLVM\bin у PATH (автоматичний вибір SDK повторно використовує 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 запускає еталонні корпуси на O0 з позиційним драйвером плюс проєктний драйвер на O2 з вимкненою спеціалізацією, запускає мутації один раз і пропускає тести full_only. Повний режим (за замовчуванням) запускає всі комбінації драйверів і політик.
• check-quality, make format і make-format.bat охоплюють файли, змінені від HEAD, а також невідстежувані файли; cmake/quality_scope.py додає одиниці трансляції, які включають змінений заголовок. Зміни в .clang-tidy, cmake/ або робочому CMake вибирають усе.
• Тестові програми не містять налагоджувальної інформації (без PDB); для перезбирання під налагоджувач слід конфігурувати з -DCLAUSE_TEST_DEBUG_INFO=ON. Вкладені нативні споживачі компонуються з runtime батьківської збірки через ClauseRuntimeTargets.cmake замість повторної компіляції; лише runtime_link збирає runtime окремо.
• Пороги та придушення попереджень ніколи не підвищуються, щоб пройти перевірку.

Фікстури та походження

• Звичайні збірки й тести не потребують ні OTP, ні його вихідного коду. Еталони (goldens) було згенеровано один раз з OTP і закомічено з хешами; перевірки хешів виконуються перед використанням будь-якої фікстури.
• Дев'ятнадцять корпусів зразків/guards містять 67,748 нативних очікуваних значень/помилок і 106 рядків семантичного приймання. Кожен нативний корпус запускає позиційний і проєктний драйвери на O0/O2 з увімкненою/вимкненою спеціалізацією, з локальними та віддаленими викликами.
• Закомічені вхідні файли Erlang написано локально (tests/fixtures/patternmatch/fragments/, препроцесорні semantic/headers/). Аудит 2026-10-03 видалив усі скопійовані файли OTP; порівняння вікнами з 60 токенів із 4,150 файлами OTP на Erlang і 1,190 файлами C/C++ не знайшло жодних збігів, крім згенерованого кортежу цілих чисел. fixture_sources забезпечує ізоляцію.
• Шість фікстур цільових програм (tests/fixtures/programs/, plan 11 step 2) містять еталони stdout/коду завершення з OTP і сьогоднішні діагностики компіляції; programs_compile перевіряє їх без OTP, а tests/compiler/programs/regenerate.py --check відтворює їх під OTP (карта фікстур).
• Еталони друку термів (tests/fixtures/printing/, plan 11 step 4) містять текст OTP ~w і erlang:display/1 для 9,542 значень, а також stdout OTP для скомпільованих викликів display; tests/compiler/printing/regenerate.py --check відтворює їх (нотатки до фікстур).
• Еталонні випадки виконуваних файлів (tests/fixtures/executables/, plan 11 step 8) — це каталоги з вихідним кодом плюс один golden.json зі stdout/кодом завершення OTP і написаним вручну шаблоном stderr; tests/compiler/executables/run.py компонує й запускає кожен із них у матриці політик/драйверів (CTest executables_<case>), а regenerate.py --check відтворює їх під OTP (нотатки до випадків).
• Перегенерація та живі аудити запускаються явно: -DCLAUSE_OTP_AUDITS=ON і tests/compiler/patternmatch/regenerate.py (інструкції). Ніщо не оновлює еталони чи прив'язку мовчки.

Дизайн тестів

Поведінка тестується через справжній CLI, згенеровані об'єктні файли, скомпоновані нативні споживачі та еталони OTP. Цільові модульні тести залишаються лише там, де вихідний код не може досягти потрібного стану, і для кожного його призначення вказано в самому тесті:

• Впроваджені бюджети та збої виділення пам'яті/вводу-виводу (project_limits, project_creation_failure, codegen_limits, codegen_write_failure, runtime_lifecycle_failure, точки впровадження збоїв у згенерованих викликах).
• Приватне володіння, недійсні/застарілі дескриптори та інваріанти відкату в синтаксичному аналізаторі, семантичному графі типів і бекенді.
• Валідація сирих слів і межі термів 32/64 біти (runtime_immediate, runtime_term_tag, abi_integers).
• Збої приймачів діагностики та знімок стабільних ідентифікаторів можливостей.

Випадки, що залежать від можливостей файлової системи (посилання, псевдоніми регістру), повідомляють про пропуски окремих випадків; вони ніколи не підміняють проходження цілого тесту.

Стан платформ і санітайзерів

• Нативне виконання згенерованого коду: лише Windows x64.
• Linux, Apple Silicon і нативне 32-бітне виконання: очікується (об'єктні файли лише перевіряються).
• ASan, UBSan і LeakSanitizer для компілятора/фронтенду: очікується. Попередньо зібраний LLVM SDK для Windows конфліктує з інструментованим кодом (annotate_string 0 проти 1; раніше також дубльовані символи алокаторів rpmalloc/ASan). Жодну перевірку не вимкнено, щоб обійти це.
• ASan лише для runtime проходить на Windows з Release-пробами, /EHsc /fsanitize=address, /MT, бібліотекою імпорту ASan від Clang і статичним runtime-перехідником (thunk), а також із DLL ASan у PATH.
• Історичні запуски на macOS arm64 (2026-09-19/20) пройшли повні збірки Debug, C++26, ASan+UBSan, лише компілятора та лише runtime для етапів синтаксичного аналізатора та проєктів; вони передують бекенду.

Історія

Стиснуто з колишніх записів для окремих кроків (оригінали в історії Git до коміту 2777c98). Якщо не зазначено інше: Windows x64, LLVM 23.1.2, прив'язка 21776803ecd1, еталонний OTP 29.1.1 / ERTS 17.1. Кількості тестів — це повні проходження CTest з нулем пропусків.

PG = крок плану зразків/guards (архівовано в .agents/00-finished.md).