Support incremental code generation in Visual Studio 2022

[sharwell]

• Split Microsoft.Windows.CsWin32 into separate assemblies targeting Roslyn 3.8 and Roslyn 4.0
• Modify MSBuild integration to use the Roslyn 4.0 assembly for design time builds inside Visual Studio 2022
• Modify the Roslyn 4.0 source generator to implement IIncrementalGenerator instead of ISourceGenerator

[sharwell]

📝 The Roslyn38 and Roslyn40 subfolders seemed the easiest way to achieve all of:

1. Share version.json
2. Not move settings.schema.json
3. Not have 3 top-level folders for one multi-targeted assembly

[sharwell]

📝 This pull request contains a few distinct examples of taking a value that frequently changes and extracting an intermediate incremental value which doesn't change as frequently. Breaking up compilation in the same manner could be a high-value win, but it's also significantly more work.

[sharwell]

The general approach for breaking up compilation would be:

• Keep a map of source document → types of interest declared in that source document
• Keep a map of metadata reference → types of interest declared in that metadata reference
• Reference the maps in the code generation step instead of directly using Compilation

This approach means a change to one source file only requires a change to one value in the maps, and then a quick lookup during the incremental output step.

[AArnott]

I like the idea. I'm puzzled by your removal of ParseOptions though as that should change infrequently. And isn't that where I'd find things like whether NRT is enabled? I don't use that yet but I may someday.

[sharwell]

I don't use that yet but I may someday.

None of this is public API. If/when you need something new, feel free to add it. Until then, omitting it means the source generator won't trigger on changes to that item.

[azure-pipelines]

Commenter does not have sufficient privileges for PR 355 in repo microsoft/CsWin32

[AArnott]

I see you split out the Microsoft.Windows.CsWin32.props file into net20 and netstandard1.0 folders. How is that better than the model of just one directly in the build folder that we had before?

[AArnott]

The build/netstandard1.0 folder should be renamed to build/netstandard1.1, because p/invoke was only first allowed in netstandard1.1.

[AArnott]

The tools/install.ps1 script should be updated to look for the analyzer dll's in the new location, right?

[AArnott]

            var inputs = context.CompilationProvider
                .Combine(languageVersion)
                .Combine(configFiles)
                .Combine(globalConfig)
                .Select((data, cancellationToken) => (compilation: data.Left.Left.Left, languageVersion: data.Left.Left.Right, additionalFiles: data.Left.Right, analyzerConfigOptions: data.Right));

Does this mean that the result will be reused so long as those inputs have not changed?
Our output can change from changes to any .cs file in the compilation. For example the user may copy and paste a generated type into their own project to modify it, and our SG immediately stops generating that type.

[AArnott]

I like the idea. I'm puzzled by your removal of ParseOptions though as that should change infrequently. And isn't that where I'd find things like whether NRT is enabled? I don't use that yet but I may someday.

[AArnott]

Do we really have to give up globbing for source files here?
What if instead of using Shared Projects, we simply used globbing in the two head projects to reach into a common directory?

[sharwell]

IMO this limitation is an unfortunate side effect of the only current recommendations for building projects with completely different dependency sets. It's been a while since I tried using globs in .projitems and it's possible it works now.

[AArnott]

FYI I have checked out your branch and resolved merge conflicts. I can't push to your branch to share the work though.

[sharwell]

Does this mean that the result will be reused so long as those inputs have not changed?

Yes, but one of the inputs is currently Compilation so this can be improved substantially. As a follow-up, you'll want to modify this to have some additional intermediate steps:

1. The list of all expected types can be generated without looking at Compilation
2. The output of (1) can be combined with Compilation to produce a map of expected type to true (needs to be generated) or false (already exists)
3. The output of (2) can be fed into RegisterSourceOutput

This refactoring is quite complex due to the current state of the generator, but offers a significant benefit where (1) only needs to be executed if NativeMethods.txt or the input metadata changes, and (3) only needs to be executed if the inputs changed or an expected type was added/removed.

[AArnott]

There are surely some caching opportunities here, but I'll close this PR since in its present form it cannot be merged, and we aren't looking at caching across invocations right now.