Согласно описанию,
Tree-sitter — это инструмент для генерации синтаксических анализаторов и библиотека инкрементного синтаксического анализа. Он может создавать конкретное синтаксическое дерево для исходного файла и эффективно обновлять синтаксическое дерево по мере редактирования исходного файла.
Но как Tree-sitter справляется с языками, в которых необходима стадия препроцессинга?
Так как препроцессор влияет на текстовое содержание, его очень сложно вписать в грамматику языка. Поэтому приходится придумывать, как с наименьшими потерями реализовать поддержку препроцессора, не проводя препроцессинг.
C/С++
tree-sitter-cpp наследует tree-sitter-c и не меняет правила для препроцессорных директив. В tree-sitter-c поступили принципиальным образом: парсер должен учитывать препроцессор как полноценную часть грамматики. Но любая директива препроцессора, модифицирующая текст (#if, #include) может появиться в середине грамматического правила и поменять его на абсолютно другое. Поэтому, для полной поддержки #if в единой грамматике необходимо сгенерировать уникальное правило директивы препроцессора для любой возможной комбинации правил. Это можно сделать, используя один из плюсов Tree-sitter: скриптабельность через JavaScript. В данном парсере ограничились только четырьмя случаями:
...preprocIf('', $ => $._block_item),
...preprocIf('_in_field_declaration_list', $ => $._field_declaration_list_item),
...preprocIf('_in_enumerator_list', $ => seq($.enumerator, ',')),
...preprocIf('_in_enumerator_list_no_comma', $ => $.enumerator, -1),Правило preproc_if используется в правилах для выражений внутри блоков и глобальной области. Правила preproc_if_in_enumerator_list и preproc_if_in_enumerator_list_no_comma встречаются в списках перечисления, а preproc_if_in_field_declaration_list, как вы уже успели догадаться, в структурах, объединениях и классах.
Такой набор правил успешно справляется с примитивными примерами:
#if 9 // (preproc_if condition: (number_literal)
int a = 3; // (declaration)
#else // alternative: (preproc_else
int b = 3; // (declaration)))
#endif //
int main(void) { // (function_definition body: (compound_statement
#if 9 // (preproc_if condition: (number_literal)
int a = 3; // (declaration)
#else // alternative: (preproc_else
int b = 3; // (declaration)))
#endif //
} // ))
struct { // (struct_specifier body: (field_declaration_list
#if 9 // (preproc_if condition: (number_literal)
int a; // (field_declaration)
#else // alternative: (preproc_else
int b; // (field_declaration)))
#endif //
}; // ))
enum { // (enum_specifier body: (enumerator_list
#if 9 // (preproc_if condition: (number_literal)
a = 2, // (enumerator)
#else // alternative: (preproc_else
b = 3, // (enumerator)))
#endif //
}; // ))Но уже в последнем примере можно сделать небольшое изменение, которое поставит tree-sitter-c в тупик:
enum { // (enum_specifier body: (enumerator_list
#if 9 // (preproc_if condition: (number_literal)
a = 2, // (enumerator)
#else // alternative: (preproc_else)
b = 3 // (ERROR (enumerator)))
#endif //
}; // ))Абсолютно валидный код на C без завершающей запятой содержит разные грамматические правила по разным веткам препроцессорной директивы: элемент перечисления с запятой и без.
Более сложный пример:
int a = // (ERROR)
#if 1 // (preproc_if condition: (number_literal)
3 // (ERROR (number_literal))
#else // alternative: (preproc_else
4 // (expression_statement (number_literal)
#endif // (ERROR))))
; //А в таком случае tree-sitter-c не может даже корректно обработать #else:
int a // (declaration)
#if 1 // (preproc_if condition: (number_literal)
= 3 // (ERROR (number_literal)
#else // )
= 4 // (expression_statement (number_literal)
#endif // (ERROR)
; // )))Если результат подстановки #if можно предсказать на основании исходного кода, результат подстановки #include абсолютно непредсказуем для парсера. Тем не менее, в грамматиках для C и C++ директива #include разрешается только в глобальной области и внутри блоков.
#include "a" // (preproc_include path: (string_literal))
int main(void) { // (function_definition body: (compound_statement
#include "b" // (preproc_include path: (string_literal))
} // ))
int a = // (declaration (init_declarator
#include "c" // (ERROR) value: (string_literal)
; // ))Csharp
В tree-sitter-c-sharp поступили так же, но чуть больше разнообразили контекст:
...preprocIf('', $ => $.declaration),
...preprocIf('_in_top_level', $ => choice($._top_level_item_no_statement, $.statement)),
...preprocIf('_in_expression', $ => $.expression, -2, false),
...preprocIf('_in_enum_member_declaration', $ => $.enum_member_declaration, 0, false),Что позволяет распарсить такой пример, благодаря специальному правилу для директивы препроцессора внутри выражений:
int a = // (variable_declaration
#if 1 // (preproc_if condition: (integer_literal)
3 // (integer_literal)
#else // alternative: (preproc_else
4 // (integer_literal))))))
#endif //
; //Но ломает работающий в tree-sitter-c пример с перечислением:
enum A { // (enum_declaration body: (enum_member_declaration_list
#if 9 // (preproc_if condition: (integer_literal)
a = 2, // (enum_member_declaration) (ERROR)
#else // alternative: (preproc_else
b = 3, // (enum_member_declaration) (ERROR)))
#endif //
}; // ))
enum A { // (enum_declaration body: (enum_member_declaration_list
#if 9 // (preproc_if condition: (integer_literal)
a = 2, // (enum_member_declaration) (ERROR)
#else // alternative: (preproc_else
b = 3 // (enum_member_declaration)))
#endif //
}; // ))Причём тут узлы ошибки соответствуют только запятым, поэтому засчитываем успешную попытку.
Тем не менее, более сложные правила типа операторов всё так же не учтены:
int a // (ERROR (variable_declaration)
#if 1 // (preproc_if condition: (integer_literal)
= 3 // (ERROR) (integer_literal)
#else // alternative: (preproc_else
= 4 // (ERROR) (integer_literal))
#endif // ))
; // (empty_statement)Другие директивы
Чем отличилась грамматика для С#, так это интерпретацией остальных препроцессорных директив. В Tree-sitter существует поле грамматики extras, которое позволяет помечать особенные правила, которые могут встречаться где угодно. Обычно в этот список добавляются пробелы и комментарии. Грамматику можно сильно упростить добавлением директив в этот список:
extras: $ => [
/[\s\u00A0\uFEFF\u3000]+/,
$.comment,
$.preproc_region,
$.preproc_endregion,
$.preproc_line,
$.preproc_pragma,
$.preproc_nullable,
$.preproc_error,
$.preproc_define,
$.preproc_undef,
],Таким образом эти директивы всё равно включены в синтаксическое дерево и участвуют в подсветке синтаксиса, но никак не влияют на остальные правила.
int a // (variable_declaration (variable_declarator
#pragma warning disable warning-list // (preproc_pragma)
= 3 // (integer_literal)
#pragma warning restore warning-list // (preproc_pragma)
; // ))Несмотря на небольшой баг в правиле preproc_pragma, всё остальное было интерпретировано правильно.
До этого пулл-реквеста #if тоже был в extras, что позволяло распарсить файлы с меньшим количеством ошибок.
Резюме
В целом, грамматики для C/С++ и C# работают достаточно хорошо, а благодаря устойчивости Tree-sitter к ошибкам, невалидные конструкции не влияют на парсинг последующего текста. Ошибку парсинга, конечно, можно заметить по неправильной подсветке синтаксиса или неправильной работе других фич редактора, реализованных с помощью Tree-sitter, но при использовании языкового сервера подсветка может быть немного исправлена за счёт Semantic Tokens. Например, clangd помечает пропущенные ветки #if как коммантарии:
Можно даже сказать, что Tree-sitter в каком-то смысле наказывает за чрезмерное использование препроцессора. Мне лично больше симпатизирует подход с помещением правил директив в extras. В следующей статье я расскажу, как решил проблему препроцессинга при написании грамматики для FastBuild, используя этот подход.