Incremental generator cookbook suggestion

[sjb-sjb]

The “augment user code” design in the incremental generators cookbook does not explain what to do if semantic/symbol information is needed during the code generation.

For example, say I need to use detailed information about the type of each property in a class. When extracting my equatable Model from the attribute’s TargetNode, I can include a string representing the type of the property as part of my Model, and use that to test equality for the purpose of managing the incremental cache. It seems easy.

But the string representation of the type is not sufficient if I need to do a deeper analysis of the type while generating code. For example, say I need to know whether the type is a reference or value type, its nullability, whether it is assignable to a certain base type or interface.

It’s true that I could do this deeper analysis as part of extracting the Model in the pipeline. But wouldn’t that take up cpu time that may go to waste? The solution would seem to be to include the semantic information (or even the entire syntaxNode) in the Model but omit it from the equality comparison. Then the reference to the syntaxNode or semantic information can be dropped after it is used to generate the code. The text representation (of the property type, in this example) would still need to be included as well since it is needed for the equality comparison.

Thoughts on this approach? If this is correct then it may make a useful addition to the cookbook.

[TahirAhmadov]

This is probably more for https://github.com/dotnet/roslyn/discussions/ as it doesn't look like a C# design conversation.

In the couple of SGs I wrote, I just store the relevant part of the output in the model as a string blob. Then I don't have to worry about saving every little detail, which can be a whole bunch of properties, methods, their types and parameter types, etc.
Besides, I need to generate the code anyway, so I get to re-use that code; if I was to save all of the pieces of information which matter separately to the model, i'm effectively duplicating a lot of the work, while running a high risk of missing something.

[333fred]

Thoughts on this approach? If this is correct then it may make a useful addition to the cookbook.

Do not do this. The cookbook is very clear that symbols should not be included in your model for a reason. If any of that info that you inspected during codegen changes, then your codegen needs to change as well; if you exclude that from your model, then your generator will get out of date in the ide. In addition, you risk rooting arbitrary amounts of old memory, and violating other invariants.

[sjb-sjb]

@TahirAhmadov That seems consistent with my comment that we are actually moving the code generation into the transform step.

[sjb-sjb]

I guess that, as @TahirAhmadov is suggesting, we can speed up the 'Model' extraction by working with enums and tokens rather than doing a lot of string manipulation. That's a bit of a gain. So the code generation would translate those specialized enums and tokens into string code.

[333fred]

So in that case, when / where in the source generator are we supposed to use semantic information?

"Use" is an interesting word. You should use the info in the generation step, but you should gather the information you will need in your transform callback. We suggest working backwards; start with the generation step. Construct a model that contains all the information you need to generate code equatably. Then, use prior steps in the pipeline to fill that model in, most usually in your FAWMN callback.

[333fred]

Also, I'd suggest, if you have discord, come and join the c# community discord in the roslyn readme; that invite should take you directly to the roslyn channel, where the team as well as a number of experienced generator authors can work with you on your specific scenario.

[sjb-sjb]

@333fred when I say "use of semantic information" I mean accessing various ISymbol or other semantic information from the compilation and performing if/then operations, looping etc based on those semantic elements. So I mean the actual place in the code where it is accessed -- the actual access of the semantic elements, not the overall conceptual use of them.

I think you are agreeing though that since the 'Model' does not contain semantic information, any use of semantic information has to occur during the transform step not during the code generation.

I guess we need to be careful to check for cancellation during the extraction of the 'Model' from the semantic information.

... especially since my generation is triggered by a class attribute while the transformation has to generate lines for all the properties in the class. It seems wasteful that I have to regenerate lines for the properties that didn't change. But I don't want the user to have to put attributes on every property.