Source Generators позволяют делать много крутых вещей
Вообще, на мой взгляд, это крайне недооценённая разработчиками фича
Возможно, в силу недостатка квалификации
Поверьте, чуть ли не каждый реальный проект имеет место, которое SG может сильно улучшить
Однако, они не всемогущи, есть узкое место, которого лично мне недавно не хватило
Ранее на канале было замечено, что нельзя строить цепочки или пайплайны из генераторов
Этому посвящён целый issue в репозитории Roslyn - https://github.com/dotnet/roslyn/issues/57239
Проблема в том, что пока не удаётся найти компромисс между тем, чтобы построить удачный пользовательский опыт для программиста и сохранить высокий перформанс инструмента
При этом скорость работы генераторов, которая действительно на уровне, является высоким приоритетом, от того задача ещё более не решаемая
С ограничением столкнулся в пет-проекте, как обычно)
Пилю, значит, интерпретатор hydrascript, и захотелось оптимизировать лексический анализ с помощью скомпилированных регулярных выражений
Но вот незадача - регулярка очень большая получается, около 600 символов в длину - очень легко в ручном режиме опечататься и налажать
Получается, что её надо генерировать на основе исходного кода конфигурации
Но вот незадача - результат генерации надо подставлять в другой генератор, уже платформенный, через атрибут
[GeneratedRegex]
А генератор1 не видит результат работы генератора2, потому что оба пользуются AST из кода, написанного руками
Здесь получилось обхитрить систему, потому что настоящего доступа к AST и семантической модели мне не требуется
Я хочу просто прочитать конфиг и выплюнуть строчку, поэтому достаточно руками забрать этот конфиг, а строку с паттерном подложить сборке через
context.RegisterPostInitializationOutput
Такие сорцы генераторы видят, потому что обычно метод используется для создания маркерных атрибутов или других вспомогательных служебных объектов
Получился такой PR, пользуйтесь)
https://github.com/Stepami/hydrascript/pull/115