Прогресс по GDScript в Godot: проверка типов вернулась

После завершения нового токенизатора и парсера, как упоминалось в предыдущих отчётах, разработчики начали работу над анализатором кода, который отвечает за проверку типов и много другого.

Это делалось ранее вторым проход внутри синтаксического анализатора. Теперь он был перенесён в другой класс, чтобы прояснить, что всё это не происходит на том же проходе, что позволяет избежать проблем с вызовом функций в другом порядке.

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

Фича, которую давно запрашивали участники сообщества, которая позволяла бы перечисления использовать как типы. В целом они считаются обычными целыми числами, но для целей проверки типов они считаются конкретным типом. Например, установка целого числа для переменной с типом enum — это нормально, но установка из другого перечисления выдаст ошибку.

Код был перенесён в другой файл, чтобы избежать проблем с циклическим включением. Это также помогает избавиться от основного файла gdscript.cpp, который уже достаточно длинный.

Некоторые предупреждения были удалены, поскольку они не применимы к новому синтаксису GDScript. Например, о возможности yield, который больше не является проблемой, поскольку ключевое слово заменено на await. Были добавлены новые, например, предупреждение о неиспользованных локальных константах.

Локальные идентификаторы теперь лучше проверяются на предмет использования. Таким образом, переменные итератора из цикла for или связывания в операторе match обрабатываются как локальные переменные, и к ним также применяются проверки. Это означает, что если вы попытаетесь объявить переменную с тем же именем, что и для привязки match, вы получите ошибку, а если вы не используете привязку, то предупреждение.

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

Это означает, что теперь можно резолвить имена констант также во всех случаях. Например, если вы пишете в своём коде PI * 2, анализатор вычислит умножение во время компиляции, что немного повысит производительность во время выполнения. Это также относится к пользовательским константам.

В прошлом году у разработчиков появилась идея кешировать скрипты, чтобы исправить проблемы с циклическими зависимостями в GDScript. Был даже пуллреквест в 3.2, но, к сожалению, он всё ещё не идеален.

Идея состоит в том, чтобы разрешить только синтаксический анализ скриптов без использования Resource Loader от самого Godot. Это позволяет коду выполнять проверку типов по зависимостям без создания цикла загрузки. Он также создаёт «неполноценные скрипты» (то есть скрипты, в которых ещё не скомпилирован код), поэтому на них можно ссылаться до фактической компиляции.

Сейчас же разработчики интегрируют эту идею с новым кодом GDScript, чтобы решить проблему на корню. Как только он заработает, его бэкпортнут на 3.2, если не будет регрессии.

Как упоминалось hfytt, планируется удалить setget и предоставить вместо этого более простое объявление свойств. Теперь это делается с помощью addendum, которое позволяет пользователям по-прежнему использовать обычные функции в качестве геттера и сеттера, если они того пожелают.

Автодополнение зависит от кода парсера, поэтому старая версия была удалена. Сейчас идёт работа над переносом его на новый синтаксический анализатор, добавляя дополнительный автокомплит, необходимый в некоторых случаях, например, для подсказок вперечислениях и автокомплите имён и аргументов аннотаций.

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

После этого начнётся работа над интерпретатором для оптимизаций.

#gamedev #gamedevnews #godot #обновление