Allow us to detect in which context a source generator is running

[xoofx]

This is an extension of the issue #59388

Within VS IDE, source generators are currently running on every key stroke, even if you optimize them using an incremental source generator and cancellation tokens. The problem is that many use cases don't need the generated code to be actually generated at each key stroke.

After 2+ years of seeing usage of source generators, I have seen a couple of interactivity mode that would be better suited depending on user scenarios (from most frequent to less frequent):

1. On save
2. At build time only
3. On every key stroke

But you can have also a mixed solution where on every key stroke you generate diagnostic messages, but you don't want to generate any code (e.g validating a regex without generating the state machine, or usually any code that you generate behind a partial method).

One year ago, I created this gist to workaround the lack of configuration for a source generator to only be triggered at build time. And I have been referring to it multiple times to several teams in my company whenever they were facing a struggle with source generator taking too much time at IDE time (while most generated code is actually not accessible for end users).

Based on this experience, I would like to request that we provide a way to detect the current interactivity context for a source generator, so that it can select different code path depending on this context in a more fine grained way.

---

[Edit] I have changed the title, because actually, even just knowing in which context a source generator is running (am I in the IDE or build time only?) should be enough to take different code path depending on this context and to early exit more quickly or to generate different code (e.g dummy code for IDE, full code with full implementation for build time)

[CyrusNajmabadi]

The answer for #59388 applies here. Incremental generators have shown that generators can be efficient and non-impactful on the IDE experience. This is the supported and workable solution that SG authors should be taking.

[ltrzesniewski]

Note that currently, RegisterImplementationSourceOutput behaves just like RegisterSourceOutput (it doesn't execute only on build, but in the IDE as well).

So, incremental source generators are certainly better in this regard, but they currently don't provide a solution for generating code at build-time only.

As an example, the following generator will beep 3 times on each keystroke in VS for some reason (and 1 time in Rider):

[Generator]
public class SourceGenerator : IIncrementalGenerator
{
    public void Initialize(IncrementalGeneratorInitializationContext context)
    {
        context.RegisterImplementationSourceOutput(
            context.CompilationProvider,
            (_, _) => Console.Beep()
        );
    }
}

(Yes, I'm aware that CompilationProvider isn't efficient when used in this way, but this should have been OK if it only ran at build-time.)

[CyrusNajmabadi]

Note: the suggested gist is not something that will work in the future, esp. if we start utilizing our external processes (like vbcscompiler) to run the generators the IDE needs. This is not something that should be done and breaks important things like idempotency.

[jasonmalinowski]

@Sergio0694 Looking at the work item for that I'm not really sure why that stalled, but we can discuss on that item.

[xoofx]

Consider for example "go to implementation", debugging, "go to definition", etc ...

Right, but if we can work around this with RegisterReferenceSourceOutput and RegisterImplementationSourceOutput It would be fine. We have cases where it can be too costly to generate code on every single key stroke, so we need to defer that, while we don't need "go to implementation" or "go to definition" (because the implementation code is hidden and only relevant for runtime, or we could generate a simpler skeleton of the code - as proposed above by @Sergio0694, just to get the code compiling). Look at what happened with ForAttributeWithMetadataName and PRs like #70754 on the runtime: you made it working for your cases (and in the end for all users, so it's good!) because you saw massive slow down. Imagine outside of these cases that we have been into some others that have the same massive slow down, and most of the time, it was for code that we would have been fine to delay until real build instead of on every key stroke (and it was for cases where it was not just an attribute to fine grain).

Also, just to confirm, but for the generated source for debugging, I would have assumed they are taken from the build, not from the IDE? (otherwise I don't understand how debugging information can be maintained correctly in synced)

[ltrzesniewski]

FWIW, I wrote a generator which emits partial classes and partial method signatures with RegisterSourceOutput, and implementations for those with RegisterImplementationSourceOutput. I don't really see the need for a separate RegisterReferenceSourceOutput, unless I've misunderstood something.

The main downside is that "go to definition" asks you which file you want to go to, since both of them are currently generated in the IDE. RegisterReferenceSourceOutput may help there I guess.

[Sergio0694]

With that setup, IntelliSense would show an error about missing partial method implementations until a real build ran, no? The point of RegisterReferenceSourceOutput is that it'd let that work fine without errors while typing.

It would also help when the actual generation part was expensive, even starting from the same cached model. That way the full generation would only run when actually needed.

[jasonmalinowski]

FWIW, I wrote a generator which emits partial classes and partial method signatures with RegisterSourceOutput, and implementations for those with RegisterImplementationSourceOutput. I don't really see the need for a separate RegisterReferenceSourceOutput, unless I've misunderstood something.

If you can use partial methods then yes that works great, but there's a lot of limitations with them that make them unsuitable for a lot of cases.

[xoofx]

Note: the suggested gist is not something that will work in the future, esp. if we start utilizing our external processes (like vbcscompiler) to run the generators the IDE needs. This is not something that should be done and breaks important things like idempotency.

It actually got broken with Rider. 🙂 So we gonna have to find another solution...

Incremental generators have shown that generators can be efficient and non-impactful on the IDE experience. This is the supported and workable solution that SG authors should be taking.

We have a source generator that is only relevant for build time but not for IDE time: This source generators needs to collect all struct/class/interface declarations in order to collect their source location, and then we generate an internal type that is going to store all these locations (large byte buffers that have strings of paths encoded in UTF8). For some assemblies, with thousands of types, it can be quite significant.

@CyrusNajmabadi how an incremental source generator can help in that case?
Should we rely on $(DesignTimeBuild) in order to not trigger such generation from IDEs?
How could we avoid entirely running this from IDE?

    class TypeFileNameScraper : ISyntaxReceiver
    {
        public Dictionary<string, List<MonoScriptInfo>> Types { get; } = new();
        public Dictionary<MonoScriptInfoKey, List<MonoScriptInfo>> MonoScriptInfoCollisions { get; } = new();

        public void OnVisitSyntaxNode(SyntaxNode syntaxNode)
        {
            if ((syntaxNode is StructDeclarationSyntax ||
                 syntaxNode is ClassDeclarationSyntax ||
                 syntaxNode is InterfaceDeclarationSyntax)
                && syntaxNode is TypeDeclarationSyntax typeDeclaration)
            {

[xoofx]

This appears to be a Syntax only SG. So just create one that stores the info per syntax tree. Then you should only have to recompute and Regen for the current file when it is edited. All other files stay the same.

That's the problem. We generate a single file for an entire assembly. This single file contains a few arrays, e.g one byte[] of all the UTF8 file paths, one array for offsets/length within this array...etc. The reason why we generate a single file is for efficiency, as we don't want at runtime to have to scan for generated types and have multi-arrays instantiated.

The byte[] of all the UTF8 file paths has to be recomputed every single time a user will add a new class/struct/interface, other arrays can be impacted if e.g you just add a comment to a file, it will shift all the line numbers, so we need to regenerate this array entirely as well. Today we are not using the incremental SG, so we get called on every single keystroke in VS, but I'm not even sure that an incremental SG would be able to help here. It feels that the incremental SG is better suited for the scenario of 1 syntax element touched => 1 file generated, while our use case is the entire set of many syntax elements across an entire assembly => 1 file generated. I don't see how this generation (many to 1) can be optimized without having a complex delta update.

Moreover, this is not a data that we want to generate during Intellisense/keystrokes. It has zero value for our users at edit time and it is only used at runtime.

So how would you solve this problem with the existing infrastructure? Help and guidance is appreciated.

[CyrusNajmabadi]

why not emit into a final type that is built out of N partial parts? Where each part contains the info related to a single input file. Then, you emit one part that 'aggregates' all the data. So, you have this:

// Partial1.cs
partial class P
{
    private static byte[] bytesForFile1 = ...
}

// Partial2.cs
partial class P
{
    private static byte[] bytesForFile2 = ...
}

// Partial3.cs
partial class P
{
    private static byte[] bytesForFile3 = ...
}

// Partial_Total.cs
partial class P
{
    private static byte[][] allByteArrays;
    static P()
    {
        allByteArrays =
        {
            bytesForFile1,
            bytesForFile2,
            bytesForFile3,
        }
    }
}

on an edit, you then only need to update a single PartialN.cs, and then only the Partial_Total.cs if the number of files changed.

It feels that the incremental SG is better suited

incremental SGs are suited to incremental problems. Namely problems where the majority of edits have no impact on the majority of the generated code. If you have a problem where you are saying "i want every edit to redo a ton a work to produce entirely different results" then SGs are a bad fit.

Moreover, this is not a data that we want to generate during Intellisense/keystrokes. It has zero value for our users at edit time and it is only used at runtime.

Then don't use an SG. Write a tool that you run at build time that computes the information you need and generates it.

So how would you solve this problem with the existing infrastructure? Help and guidance is appreciated.

If using SGs is a requirement, reformulate the generation domain to one that can be incremental.

If using SGs is optional (as it sounds like based on your explanation), and you actually need to compute something expensive, but rarely, then just write a simple tool to do this work for you. There's no need for SG in the first place.

[xoofx]

why not emit into a final type that is built out of N partial parts?

Mainly to avoid lots of allocations and the pressure on the GC (that is the one from Mono, not from CoreCLR, so a lot less efficient), as we have also lots of assemblies.

Then don't use an SG. Write a tool that you run at build time that computes the information you need and generates it.

Understood for SG. We can't afford to have a tool that runs at build time, as it would require us to launch Roslyn a second time, before the first compilation, pass exactly the same context than for the real build (defines, references...etc.). Not only we want to lower the impact at IDE time, but the impact at build time should not involve relaunching an entire Roslyn instance.

If we were passing the MSBuild/VS IDE $(DesignBuildTime) variable to the analyzer, is it something that is honored by Visual Studio when interacting with Roslyn/Roslyn analyzers? So that we could get access to it from AnalyzerConfigOptions or similar, also related, issue #49978 or an option we could add on e.g AnalyzerOptions.IsDesignBuildTime?

[kzu]

I indeed use the $(DesignTimeBuild) property for exactly this purpose and it works great. It's set as a global property by VS when it runs the design-time build (you can see this by using the Project System Tools extension in VS and the msbuildlog.com tool). You just make it a CompilerVisibleProperty and check it from the generator. I'm not sure Rider does the same though.

[xoofx]

Yep, I had recently a look and I could see it as well. It should cover the usage, thanks for confirming!