Побайтовая сверка со свидетелем — главный метод проверки в проекте

Метод, на котором стоит всё: одна и та же программа даётся свидетелю на JavaScript и эталону на flang, и выходы обязаны совпасть знак в знак — не «похоже», а те же вердикты, коды отказов, тексты, позиции.

Почему это сильнее тестов. Тест проверяет то, что автор придумал проверить. Сверка проверяет всё, что различает две реализации, включая то, о чём автор не подумал. Отсюда числа вроде «15 828 утверждений, расхождений 0» и «2318 примеров из 2318, витки совпали число в число».

Счёт шагов сверяется тоже, и это ловит то, что не ловит значение. Пример: порча «постусловие перестало отменять хвостовую оптимизацию» оставляет результат правильным и меняет только число шагов, 616 против 776. Без счёта шагов она прошла бы незамеченной.

Где метод не работает. Для машинного кода сравнивать не с чем — свидетеля нет. Это главная причина, по которой свой генератор машинного кода дольше, чем кажется по строкам: проверять придётся запуском и сравнением поведения, а это в разы медленнее и ловит меньше.

Уточнено замером 18 августа 2026 (docs/native-x86-backend.md, §8): это верно наполовину. Сверка печати с печатью — «x86 от свидетеля == x86 от flang₁ == x86 от flang₂» — для машинного кода сохраняется целиком, потому что чужого свидетеля она и не требует. Теряется другое: 194 предупреждения cc под -Werror, которые сегодня ловят ошибку бэкенда ДО запуска и указывают на строку. Оракулов остаётся один вместо трёх.

Тот же приём в другой области — контрольная сумма в замере скорости: checksum-inside-the-benchmark.

Связано: a-removal-must-turn-a-test-red, four-pieces-of-javascript, checks-that-stopped-comparing, checksum-inside-the-benchmark