Modernize to Incremental Source Generators

[viceroypenguin]

No description provided.

[CLAassistant]

All committers have signed the CLA.

[viceroypenguin]

@kzu This PR strictly updates all generators to use incremental generator technology. Other PRs will follow.

[kzu]

To fix the dotnet-format check, just run dotnet format on the repo root and commit the changes

[kzu]

Hey @viceroypenguin , thanks a lot for tackling this! I've been meaning to spend time on it for months now, he. So glad you could work on it!

It looks really nice and focused on just the conversion, which is very much appreciated.

[viceroypenguin]

To fix the dotnet-format check, just run dotnet format on the repo root and commit the changes

Done

[kzu]

Ok, just rebased on main to get minor changes from there

[viceroypenguin]

You bet! Finally looking into doing ThisAssembly.EmbeddedResources, so cleaning things up first seemed to make sense.

[viceroypenguin]

@kzu - unrelated: would you be opposed to me changing the SourceItemType of the items for ThisAssembly.Strings? "EmbeddedResource" would be accurate for ThisAssembly.EmbeddedResource, while "Strings" or "ResourceString" would be more appropriate for ThisAssembly.Strings.

[kzu]

Wouldn't both generators be able to work off of the same SourceItemType of EmbeddedResource? The underlying generator would require a run-time embedded resource anyway, right? If so, I think the new generator could leverage the same item type as the Strings one?

[viceroypenguin]

Couple factors at play here:

• .Strings wants to import the text of the embedded resource so that it can do XML parsing. This means the full text of the resource is part of the incremental cache - it would be better for .Strings not to accidentally include .EmbeddedResources (knowing at some level that it won't due to the add'l metadata filter in StringsGenerator.cs)
• .EmbeddedResources probably does not want to import the resx files - generally those will get accessed via ResourceManager instead of EmbeddedResources since the .resx file itself is not important to the consumer. Though if it did, it really wouldn't be a significant effect.
• The .Strings target will possibly import EmbeddedResource twice for .resx files, since they will be included via the .Strings target and the .EmbeddedResources target

[kzu]

Ah, yeah, I understand the difference now.
Yeah, changing the Strings one makes sense. Thanks for your patience in clarifying!