Adding analyzer/fixer for the Regex Source Generator

[joperezr]

Fixes #68147

FYI: @meziantou

Adding Roslyn analyzer and code fixer that will suggest the use of the Regex Source Generator whenever possible.

Pending items before merging:

• Adding tests for the analyzer and fixer
• Adding documentation into docs.microsoft.com around the new diagnostic. cc: @carlossanlop @buyaa-n do I need to do this before merging the PR into main? Or is it ok to merge and then subsequently add the diagnostic's documentation? Also, since this is the first analyzer I write, am I missing something apart from public documentation?

[ghost]

Tagging subscribers to this area: @dotnet/area-system-text-regularexpressions
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #68147

FYI: @meziantou

Adding Roslyn analyzer and code fixer that will suggest the use of the Regex Source Generator whenever possible.

Pending items before merging:

• Adding tests for the analyzer and fixer
• Adding documentation into docs.microsoft.com around the new diagnostic. cc: @carlossanlop @buyaa-n do I need to do this before merging the PR into main? Or is it ok to merge and then subsequently add the diagnostic's documentation? Also, since this is the first analyzer I write, am I missing something apart from public documentation?

Author:	joperezr
Assignees:	-
Labels:	area-System.Text.RegularExpressions
Milestone:	-

[stephentoub]

@mavasani, could you help review this as well?

[mavasani]

Is there a reason to add this property bag to the diagnostic instead of computing all the required information in the fixer itself? Given the diagnostic location, the fixer can fetch the required syntax node from the location using root.FindNode(span) API. You can get the semantic model from the document using document.GetSemanticModelAsync API and then use semanticModel.GetOperation(node) API to get to the IInvocationOperation.

[mavasani]

NOTE: If you feel your current approach is more maintainable and makes it more easier to understand for anyone new to this code, then it seems fine as well. We generally don't recommend using such a property bag unless needed as you are now adding an additional dependency between the analyzer and fixer internals, which might make it more harder to maintain or understand.

[mavasani]

So seems like you are already computing the operation to fix in the fixer. Wondering if it is easier to avoid the property bag on the diagnostic and just move all the computations to the fixer itself.

[carlossanlop]

Adding documentation into docs.microsoft.com around the new diagnostic. cc: @carlossanlop @buyaa-n do I need to do this before merging the PR into main?

@joperezr You can add documentation later, as long as it's merged before RC1 is snapped.

[carlossanlop]

Here are the unit tests for LibraryImportGenerator, within the dotnet/runtime repo: https://github.com/dotnet/runtime/blob/bcded447f1558e7f891f3411f566db49f2ced6ec/src/libraries/System.Runtime.InteropServices/tests/LibraryImportGenerator.UnitTests/AdditionalAttributesOnStub.cs

Edit: Nevermind, does not seem to be analyzer tests. But from our conversation, seems you already know how to solve the test challenge.

[joperezr]

Still need to fix the top-level statements and address a couple of comments I missed.

[joperezr]

All of the failed checks are just cancelled builds for pipelines that shouldn't be running in the first place so the rest of the builds are green, so I'm merging now.

[danmoseley]

@joperezr maybe I missed discussion of it, but what was the reasoning behind not removing RegexOptions.Compiled in the output of the fixer? It's ignored, so it just seems like noise.

[stephentoub]

If the pattern doesn't support source code generation (e.g. IgnoreCase backteference), you still want the Regex ctor emitted as a backup strategy to use Compiled if the dev asked for it.