Лабораторная №6 — задание 6.2D #

Нужно реализовать и покрыть тестами проверку правил семантики и наполнение AST атрибутами до начала интерпретации кода.

⚠️ Обратите внимание #

Это задание выполняется по спецификации правил семантики, подготовленной аналитиком в задании 6.2A.

• Спецификация должна появиться до начала кодирования — так же, как и в реальных проектах.
• Вы можете составлять спецификацию совместно с аналитиком, а затем приступить к реализации.
• Ждать проверки спецификации преподавателем не нужно.

Порядок выполнения #

1. Получите спецификацию семантики для своего языка программирования у аналитика
2. Напишите (или допишите) список тестов правил семантики в формате markdown
3. Реализуйте обходы AST для проверки правил семантики и наполнения AST атрибутами
   • рекомендуется следовать подходу TDD или ATDD
   • выделите модуль src/Semantics для семантических проверок
   • внесите доработки в остальные модули

Рекомендации к модулю Semantics #

1. Рекомендуется тестировать проверки приёмочными тестами (в основном негативными)
   • Позитивный приёмочный тест задаёт код и входные данные программы, а затем запускает интерпретатор и проверяет все результаты (например, вывод и код возврата программы)
   • Негативный приёмочный тест задаёт код и входные данные программы, а затем запускает интерпретатор в ожидании исключения определённого типа
2. Рекомендуется реализовать проверку семантики путём нескольких обходов дерева, например:
   • ResolveNamesPass — сопоставляет имена символов с объявлениями символов и добавляет к узлам AST ссылки на сопоставленные объявления
   • ResolveTypesPass — проверяет семантику типов данных
   • CheckSemanticsRulesPass — проверяет прочие правила семантики
3. Рекомендуется добавить в модуле Semantics класс-фасад, позволяющий лаконично и правильно применить все проверки семантики к заданному AST
   • имеется ввиду шаблон проектирования «Фасад» (Façade pattern)

Требования к списку тестов #

Список тестов должен соответствовать спецификации, подготовленной аналитиком:

1. Список должен быть полным — каждое правило из спецификации должно быть покрыто хотя бы одним тестом
   • Не обязательно на каждую фразу спецификации делать отдельный тест, поскольку один тест может проверить несколько вещей
   • С другой стороны, может быть полезным на одно правило спецификации сделать несколько тестов под разные варианты (например, разные комбинации дубликатов имён)
2. Список тестов должен быть корректным — в нём нет лишних пунктов, противоречащих спецификации
   • Антипример: в спецификации семантики указано, что break может быть в метке case внутри switch, но в языке нет конструкции switch-case

Справочные материалы #

1. Каноничный TDD и список тестов
2. Пример PsTiger
3. Лекция 11. Атрибутные грамматики