Блог

Четыре языка делили одно расширение .tri

2026-09-08 · 6 мин чтения

[отчёт в смерженном PR #793] Генератор VIBEE теперь называет входы Markdown, TOML и t27 вместо молчаливого создания пустых VIBEE-модулей, а нераспознанные файлы сохраняют прежний путь.

#Compiler#Parser#Testing#Reproducibility

[отчёт в смерженном PR #793] Генератор VIBEE теперь различает входы Markdown, TOML и t27, которые делят расширение .tri, вместо молчаливой обработки их как пустых VIBEE-модулей. Нераспознанные файлы сохраняют прежний путь.

Это исправление границы парсера, а не заявление о новом языке. В отчёте PR корпус разбит так: 1 065 YAML-файлов VIBEE, 14 t27-блоков, 32 Markdown-файла, 13 TOML-файлов, 10 файлов с комментариями в начале и 3 практически пустых файла — всего 1 137 файлов.

Пустой модуль с нулём behaviours не был безобидным результатом

[отчёт проверки] До изменения каждый не-YAML-вход на этом пути давал Types: 0, Behaviors: 0, записывал болванку и завершался с кодом 0. Корпусный гейт мог поэтому принять пустую интерпретацию за корректную спеку без behaviours.

Смерженное изменение сообщает об отказе по имени для 62 файлов и о продолжении обработки 1 075 файлов; в отчёте PR регрессий корпусного гейта нет. Таблица корпуса объясняет распознанные формы, но не утверждает, что теперь классифицирован каждый .tri-файл.

Порядок распознавания меняет сообщение об ошибке

[отчёт PR #793] Markdown проверяется раньше t27. specs/storm_main.tri — Markdown-документ с Zig-функцией executeStormCommand; маркеры t27 могли сработать первыми и назвать язык неправильно. Используется ATX-заголовок, начинающийся с ## , а одиночный # оставлен совместимым с комментариями VIBEE.

TOML распознаётся по заголовку секции вроде [section] вместе с формой key = "value". Порядок проверок задан явно: диагностика должна назвать диалект, из-за которого файл непригоден для этого генератора, а не просто сообщить о пустом результате.

Разрешающий путь оставлен намеренно

Десять файлов, начинающихся с комментариев, и 3 почти пустых файла остаются на прежнем пути. PR выбирает границу с защитой от ложных отказов: распознанная форма Markdown, TOML или t27 получает именную ошибку, а нераспознанный файл не объявляется новым языком по догадке.

Что сообщает проверка смерженного PR

zig build codegen-corpus: код возврата 0, регрессий в отчёте нет.
zig build test: код возврата 0.
zig build astcheck: код возврата 0.
zig fmt --check src/ tools/: код возврата 0.

Что установлено, а что нет

Смерженный PR устанавливает более точную программную диагностику для трёх распознанных диалектов с общим .tri и сохраняет описанное разрешающее поведение для форм, которые не совпадают с этими признаками. Это результат компилятора и корпусного гейта.

Числа и результаты команд приведены по отчёту PR #793; в этом запуске блога они независимо не повторялись.
Изменение не устанавливает поведение FPGA или AX7203, timing, энергию, качество модели или результат на физическом кристалле.
Детектор основан на признаках; это не полный парсер и не доказательство классификации каждого .tri-файла.
Результат ничего не говорит о каталоге числовых форматов из 83 форматов или о сравнении точности с takum.

Чего это не решает

Числа и результаты команд приведены по отчёту PR #793; в этом запуске блога они независимо не повторялись.
Это результат программного репозитория. Он не устанавливает поведение FPGA или AX7203, timing, энергию, качество модели или результат на физическом кристалле.
Детектор основан на признаках; это не полный парсер и не доказательство классификации каждого .tri-файла.
Результат ничего не говорит о каталоге числовых форматов из 83 форматов или о сравнении точности с takum.

Пруфы

Открыть интерактивную версию Read in English Все статьи

Поработаем вместе

Хотите так же проверить собственный дизайн?

Я аудирую RTL и строю независимые побитово точные модели, затем провожу результат через синтез и, когда это полезно, проверяю на плате Artix-7. Первый модуль проверки — бесплатно.

Обсудить задачу Услуга верификации