T27.AI

Блог

Частичному модулю нужен собственный вердикт

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

Генераторы JavaScript и TypeScript получили явные записи о пропусках: Spec Explorer теперь отличает полезный, но частичный модуль от полного результата и от неудачной компиляции.

Сгенерированный модуль может быть синтаксически правильным и при этом непригодным для использования. А может быть полезным, но неполным. Если оба случая спрятать за одной красной или зелёной меткой, разработчик не получит главного ответа перед импортом файла. Недавняя работа над JavaScript и TypeScript в t27 сделала это различие частью результата компилятора, а не догадкой интерфейса.

Новый backend проявил старое допущение

[доказано] JavaScript появился в Spec Explorer со смерженным PR #1067 в Trinity, а TypeScript — с #1074. В upstream-репозитории t27 PR #4502 сделал генерацию значений общей для двух направлений вместо копирования реализации. Экранирование, зарезервированные имена и константные выражения получили один источник. Это полезное свойство архитектуры, но общий код одинаково хорошо распространяет и исправление, и ошибку.

Одной из ошибок оказался идентификатор, который генератор печатал, не проверяя, сможет ли полученный модуль на него сослаться. Объявление с этим именем могло быть отклонено самим backend, находиться ниже по файлу до доступности значения или обозначать примитивный тип вместо значения. Комментарий называл такую ссылку уже объявленной. Но комментарий ничего не проверял.

[измерено] В расследовании из смерженного t27 PR #4529 использовали три разных инструмента. Синтаксическая проверка находила повторные экспорты. Импорт каждого артефакта обнаруживал несвязанные имена, которых синтаксическая проверка не видела. Строгая проверка TypeScript обнаруживала потерянные записи о пропусках и значения вариантов перечислений. Это три самостоятельных вопроса: разбирается ли модуль, загружается ли он и описывают ли объявления пригодные значения.

Пропуск становится частью результата

Исправление отдельно отслеживает выведенные, отклонённые и объявленные имена. Ссылка разрешается по этим множествам, а не печатается в надежде на успех. Для пользователя важен ещё один результат: объявление, которое нельзя вывести, явно попадает в неизменяемый список __NOT_EMITTED__. Артефакт сохраняет полезные объявления, но больше не притворяется полной реализацией спецификации.

[доказано] Смерженный PR #1084 в Trinity приносит этот компилятор на сайт и читает количество пропусков прямо из его ответа. Интерфейс не ищет удобную строку внутри сгенерированного кода. Компилятор уже знает, что именно он не вывел; восстанавливать это знание вторым парсером означало бы создать ещё одно место для расхождений. Каталог записывает partialBackends: частичный результат не получает отметку полностью работающего, а отказ другого backend по-прежнему имеет приоритет над предупреждением.

Есть и небольшое, но важное решение в подсчёте. Количества пропусков JS и TS объединяются через максимум, а не складываются: общее объявление, пропущенное обоими направлениями, не должно превращаться в два пропуска каталога. Это свойство данной пары backend, а не универсальное доказательство того, что максимум устраняет дубликаты любых множеств.

Что действительно посчитано в снимке

[измерено] Manifest из #1084 содержит 1 419 спецификаций: 1 017 в категории работающих, 184 предупреждения и 218 ошибок. Отдельный признак частичного результата есть у 71 спецификации. Проверка manifest на изученной ревизии main подтверждает: 211 ошибок возникают до получения AST; ещё семь файлов разбираются, но теряют один backend — шесть verilog_hir и один verilog. Эти семь нельзя потерять в удобной фразе, будто все оставшиеся ошибки относятся к парсеру.

Это классификация конкретного корпуса конкретным компилятором, а не оценка производительности. В предыдущем снимке сайта было на пять спецификаций меньше, поэтому изменение итогов нельзя считать чистым экспериментом над неизменной выборкой. Upstream PR сообщает об успешном импорте 1 205 полученных артефактов, но этот результат относится к его корпусу из 1 414 спецификаций. Нельзя переносить тот знаменатель на более поздний снимок сайта.

Что получает разработчик

Практическое улучшение — третий возможный ответ. Полный, частичный и неудавшийся результат теперь ведут к разным решениям. Потребитель может изучить список пропусков до того, как довериться модулю. Каталог может объяснить предупреждение вместо того, чтобы скрывать неполноту успешной меткой. Оставшиеся ошибки парсера и backend требуют отдельной работы. Эти изменения не устанавливают корректность исполнения каждой программы, скорость оборудования или полную поддержку языка.

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

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

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

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

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