Валідація

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

Останні записані перевірки на хості розробки Windows x64 (clang-cl і LLVM SDK 23.1.2, /MT, _ITERATOR_DEBUG_LEVEL=0); наступні кроки записують свої в .agents/00-finished.md:

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

З командного рядка розробника 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, one unit per header
cmake --build build/debug --target check-quality-all  # whole tree

• CLAUSE_TEST_MODE=fast запускає еталонні корпуси на O0 positional і проєкт на O2 з вимкненою спеціалізацією, виконує мутації один раз і пропускає тести full_only (окремі проєкти-споживачі, як-от runtime_generated_link, вимірювання, аудит хостової OTP library_freshness і повільні сценарії linking_lto, linking_exports, linking_compile_cache, programs_compile та transforms_cache). Повний режим (типово) запускає всі комбінації драйверів і політик.
• Довгі тести, які керуються скриптом Python або CMake, мають фіксовану COST у CTest: CTest визначає вартість обгортки з її власного малого процесорного часу й запускав би їх останніми.
• Чутливі до навантаження тести (CLAUSE_LOAD_SENSITIVE_TESTS у кореневому CMakeLists.txt: frontend_cli, codegen_examples, linking_debugger, executables_applications) перевищували час очікування або програвали часові перегони лише під час повного паралельного запуску. Вони мають DEPENDS на всі інші тести, тому починаються після завершення решти вибірки й отримують процесори у своє розпорядження; збій залежності не призводить до їх пропуску.
• CLAUSE_TEST_TIMEOUT_SCALE=N множить обмеження на один запуск для виконавця еталонів (60 с) і виконавця семантичних випадків (15 с) для інструментованих збірок.
• check-quality, make format і make-format.bat охоплюють файли, змінені від HEAD, і невідстежувані файли; cmake/quality_scope.py додає для кожного зміненого заголовка одну одиницю трансляції, що його включає (власне джерело, інакше першого користувача, з даних залежностей Ninja будь-якої конфігурації; інші залежні одиниці заголовка залишаються для check-quality-all у повній перевірці), а для clang-tidy — одиниці, команда компіляції яких відрізняється від записаної останнім успішним запуском (build/debug/quality/tidy-commands.json), тому зміна правила збирання повторно перевіряє лише змінені нею одиниці. Зміни .clang-tidy чи скриптів tidy вибирають усе, як і зміни правил збирання до першого записаного запуску.
• CLAUSE_OPTIMIZED_COMPILER (за замовчуванням ON) компілює clau і бібліотеки компілятора з оптимізацією також у збірках Debug, зберігаючи їхню налагоджувальну інформацію та бюджети виведення типів Debug; тести проводять більшу частину часу в clau. Коли збій компілятора треба пройти покроково, слід конфігурувати з -DCLAUSE_OPTIMIZED_COMPILER=OFF, перезібрати й знову запустити тест, що не пройшов.
• Тестові програми не містять налагоджувальної інформації (без PDB); для перезбирання під налагоджувач слід конфігурувати з -DCLAUSE_TEST_DEBUG_INFO=ON. Вкладені нативні споживачі компонуються з runtime батьківської збірки через ClauseRuntimeTargets.cmake замість повторної компіляції; лише runtime_link збирає runtime окремо.
• Пороги та придушення попереджень ніколи не підвищуються, щоб пройти перевірку. Налаштовано два винятки для сторонніх бібліотек (рішення користувача): cmake/tidy_filter.py відкидає звіти статичного аналізатора, розташовані в заголовках Boost (хибні спрацювання Boost.Multiprecision щодо сховища лімбів у Linux, які переписування коду, що викликає, лише переносить), і рахує їх у виводі, а bugprone-exception-escape ігнорує bad_array_new_length (конструктори переміщення map/set у MSVC виділяють пам'ять; збій виділення однаково фатальний).
• clang-tidy перевіряє заголовки проєкту на кожному хості: фільтр заголовків приймає роздільники / і \.

Linux

Та сама перевірка працює в Linux із зафіксованим LLVM 23.1.2 Linux SDK як компілятором хоста (CC/CXX з його bin/), системною libstdc++, Ninja і CMake 3.28 або новішим. Boost 1.90 і toml++ 3.4.0 беруться зі встановлених пакетів або розпаковуються в thirdparty/ (boost_1_90_0/, tomlplusplus-3.4.0/); лише у Windows вони завантажуються. ld.lld з архіву релізу компонується з ICU 70 (Ubuntu 22.04), а його lldb — з Python 3.14; на хостах без них linking_lto потребує ICU 70 у LD_LIBRARY_PATH, а linking_debugger використовує GDB.

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

check-quality (Lizard, clang-tidy) запускається лише на хості розробки під Windows; інші хости збирають і запускають тести (одного разу перевірка пройшла без зауважень у Linux, див. історію).

Інші цілі

32-бітні цілі й цілі ARM перевіряються без компілятора, зібраного для них (для цих хостів немає LLVM SDK):

• Збірка лише runtime (-DCLAUSE_BUILD_COMPILER=OFF -DBUILD_TESTING=ON) для цілі запускає там тести runtime і ABI: нативно, в userland цілі (chroot) або через емулятор хоста (qemu binfmt).
• tests/compiler/executables/cross.py запускає кожен еталон виконуваних файлів і кожну фікстуру програм з clau цього хоста, --target-triple, архівом runtime тієї збірки й --linker, що досягає бібліотек цілі (run.py --target-option передає їх далі).

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

• Звичайні збірки й тести не потребують ні OTP, ні його вихідного коду. Еталони (goldens) було згенеровано один раз з OTP і закомічено з хешами; перевірки хешів виконуються перед використанням будь-якої фікстури.
• Дев'ятнадцять корпусів зразків/guards містять 67,748 нативних очікуваних значень/помилок і 106 рядків семантичного приймання. Кожен нативний корпус запускає позиційний і проєктний драйвери на O0/O2 з увімкненою/вимкненою спеціалізацією, з локальними та віддаленими викликами.
• Закомічені вхідні файли Erlang написано локально (tests/fixtures/patternmatch/fragments/, препроцесорні semantic/headers/); fixture_sources забезпечує ізоляцію від вихідного коду OTP.
• Шість фікстур цільових програм (tests/fixtures/programs/) містять еталони stdout/коду завершення з OTP та їхні діагностики компіляції; programs_compile перевіряє їх без OTP, а tests/compiler/programs/regenerate.py --check відтворює їх під OTP (карта фікстур).
• Еталони друку термів (tests/fixtures/printing/) містять текст OTP ~w і erlang:display/1 для 9,542 значень, а також stdout OTP для скомпільованих викликів display; tests/compiler/printing/regenerate.py --check відтворює їх (нотатки до фікстур).
• Еталонні випадки виконуваних файлів (tests/fixtures/executables/) — це каталоги з вихідним кодом плюс один 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 x86-64. Результати для 32-бітних цілей і ARM (тести runtime та крос-скомпоновані еталони) — в історії.
• Apple Silicon: не перевірявся відтоді, як з'явився бекенд.
• ASan, UBSan і LeakSanitizer для компілятора й runtime: Linux x86-64, одна комбінована конфігурація Debug (-fsanitize=address,undefined -fno-sanitize=vptr -fno-sanitize-recover=undefined), повний CTest з CLAUSE_TEST_TIMEOUT_SCALE=10 (інструментований код працює в кілька разів повільніше): жодного звіту санітайзера. Компілятор, runtime і тестові програми інструментовано; програми, які компонує clau, беруть runtime санітайзера з обгортки clang++ у PATH, а їхній згенерований код не інструментовано. Чотири тести з упровадженою відмовою хоста (codegen_failure_*, runtime_lifecycle_failure, runtime_memory) лежать поза межами ASan: його operator new аварійно завершується на неможливому розмірі замість кидання винятку.
• ThreadSanitizer: Linux x86-64, та сама область інструментування з -fsanitize=thread; повний CTest і тести паралельності, кожен п'ять разів, не повідомляють про гонки. Також поза межами: два тести, що замінюють operator new.
• У Windows попередньо зібраний LLVM SDK і далі конфліктує з інструментованим кодом (annotate_string 0 проти 1).
• 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 для етапів синтаксичного аналізатора та проєктів; вони передують бекенду.

Бенчмарки

Ручне порівняння продуктивності з Erlang/OTP. Воно ніколи не входить до CTest, перевірки комітів чи check-quality, і лише йому потрібен Erlang/OTP на хості; результати — це свідчення для конкретного хоста, а не результати перевірки.

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

• Обидва налаштовують і збирають Release clau і runtime у build/bench, а потім запускають benchmarks/run.py (--help перелічує його опції).
• Програми: benchmarks/bench_*.erl з bench_util.erl, які без змін збирають erlc і clau -O2. Кожна вимірює свої ядра за допомогою erlang:monotonic_time/1 після одного виклику для розігріву й друкує BENCH <name> <nanoseconds>: генерація даних, обробка даних, збирання сміття, передавання повідомлень, файловий ввід-вивід (у порожньому тимчасовому робочому каталозі в build/bench/runs, усередині репозиторію, щоб на нього поширювалося антивірусне виключення для репозиторію), сокети loopback і бібліотеки (libraries.qlc: перетворення запитів через qlc_pt і модулі за зразком випадків qlc_SUITE, вимірювані разом). Кількість ітерацій забезпечує тривалість кожного ядра в OTP 1–2 с, тож роздільність таймера й шум хоста малі порівняно з нею; сокетні ядра збільшують роботу на з’єднання, а не кількість сокетів. Поза вимірюванням і розігрів, і вимірювані виклики чекають завершення всіх породжених ними процесів (помилка processes_left після 10 с). Кожне ядро працює у власному новому процесі, який завершується до початку наступного ядра, тому жодне ядро не оплачує купи, збільшені попереднім.
• Кожен запуск програми має власний об’єкт завдання Windows або сеанс POSIX; наступний запуск починається після завершення всіх його процесів, а залишки, живі через 30 с після виходу, примусово завершуються й повідомляються як збій.
• CPU: кожен процес запуску, як OTP, так і Clause, працює на наборі --cpus: performance (типово: ядра з найвищим EfficiencyClass у Windows, /sys/devices/cpu_core/cpus або найбільшим cpu_capacity у Linux, тобто P-ядра гібридного CPU, інакше всі CPU), all, список на кшталт 0-15 чи 2,4,6 або шістнадцяткова маска на кшталт 0x5554. У Windows об’єкт завдання запуску містить обмеження спорідненості до відновлення програми, у Linux програма задає його до exec; macOS не підтримує прив’язку й працює без неї. І OTP, і Clause запускають один активний планувальник на CPU набору, без прив’язки до окремих CPU. Заголовок звіту й кожен запис історії (cpus) вказують набір; відношення запусків на різних наборах непорівнянні.
• Системи на тому самому хості в одному запуску, почергово: OTP з типовим варіантом (JIT), OTP -emu_flavor emu, якщо встановлено (інсталятор для Windows постачає лише JIT, тож ці стовпці показують n/a), Clause HEAD на O2 і з --lto, а також попередній коміт Clause (типово: найновіший коміт, старіший за HEAD щонайменше на один день; --baseline REV, --no-baseline), зібраний у кешованому worktree в build/bench-base/<hash>, що ділить thirdparty/.
• Звіт: для кожного ядра медіана запусків --repeat (типово 3) у мілісекундах із шістьма десятковими знаками та розкид, зміна Clause O2 проти кожної системи (+N%: Clause швидший, інша система витрачає на N% більше часу; -N%: Clause витрачає на N% більше; (Fx) — відношення часу) з геометричним середнім, --lto проти OTP й O2, повний час програм зі стартом, розміри виконуваних файлів, помилки й тайм-аути (--timeout, 600 с на запуск). Типовий запуск вимірює приблизно 15 хвилин.
• Розміри виконуваних файлів у байтах: кожна програма з -O2, з --lto та з -O0 (додаткова збірка лише вимірюється, ніколи не запускається; обидві пропускаються за --no-lto) і базова версія з -O2, з підсумковим рядком і змінами O2 проти O0, --lto проти O2, --lto проти O0 й O2 проти базової версії (-N% — менше); а також clau на HEAD і базовій версії. Історія зберігає їх як sizes_bytes (programs: програма → стовпець → байти, clau: head/baseline → байти; null, якщо збірка не вдалася).
• Історія: benchmarks/history/<host>.json зберігає один запис на день запуску (дату запуску, хеш HEAD і дату коміту, медіани Clause, OTP і базової версії, розміри й відношення часу Clause otp_ratio та baseline.ratio для кожного ядра), benchmarks/history/reports/<host>/<day>-<hash>.txt — текстові звіти; повторний запуск того самого дня замінює обидва. Записи й звіти запусків більш ніж за 183 дні до найновішого видаляються; запуск із незакоміченими змінами джерел потрапляє до звіту, але не записується. Таблиці історії звіту показують відношення за останні 8 днів запусків, які залишаються порівнянними, коли ядра змінюють обсяг роботи; записи до масштабування на 1–2 с зберігають лише відношення. Каталог історії ігнорується Git: він залишається на хості запуску.
• Лістинги: з --listings перед вимірюванням запуск записує лістинги --print-asm і --print-ir кожної програми (з bench_util, --entry <program>, тож недосяжний бібліотечний код пропускається, як у виконуваному файлі) поруч зі звітами як <program>.debug.asm / <program>.debug.ll (-O0) і <program>.release.asm / <program>.release.ll (-O2, код, який виконує стовпець clause-o2), замінюючи лістинги попереднього запуску, зокрема з --no-history і незакоміченими змінами. --print-ir — це IR до конвеєра LLVM; коментарі асемблера цитують IR після нього. Програма, яка не компілюється, втрачає свої застарілі лістинги.

Історія

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

PG = крок плану зразків/guards; записи кроків plan 11 архівовано в .agents/00-finished.md.