Adding analyzer/fixer for the Regex Source Generator (#68976)

[joperezr]

Adding analyzer/fixer for the Regex Source Generator

This feature just missed the snap for preview 5 for a few hours, and we would really like to have it be part of preview 5 in order to get feedback on the analyzer, as well as get a (hopefully) larger exposure to the source generator to folks consuming the preview.

Description

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

This change was merged to main branch here: #68976

Customer Impact

After this goes in, customers using Regex in their apps with constant and known-at-compile-time inputs will get an informational diagnostic suggesting converting into the Regex Source Generator instead, which is expected to be a lot more performant (plus many other benefits) than the rest of the engines that would be used instead. It also provides a code-fixer so that if the customer does decide to use the source generator, all of the changes will be done for them.

Regression?

• Yes
• No

Risk

• High
• Medium
• Low

All Roslyn analyzers and code-fixers are visible to the user since they are features for the IDE, which is why they always come with some risk. That said, any issues that the fixer and analyzer may have will cause the IDE to automatically turn off the analyzer/fixer as a mitigation. We mainly want to get this out in preview 5 in order to help flush any issues that may exist with it.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[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

---

Adding analyzer/fixer for the Regex Source Generator

This feature just missed the snap for preview 5 for a few hours, and we would really like to have it be part of preview 5 in order to get feedback on the analyzer, as well as get a (hopefully) larger exposure to the source generator to folks consuming the preview.

Description

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

This change was merged to main branch here: #68976

Customer Impact

After this goes in, customers using Regex in their apps with constant and known-at-compile-time inputs will get an informational diagnostic suggesting converting into the Regex Source Generator instead, which is expected to be a lot more performant (plus many other benefits) than the rest of the engines that would be used instead. It also provides a code-fixer so that if the customer does decide to use the source generator, all of the changes will be done for them.

Regression?

• Yes
• No

Risk

• High
• Medium
• Low

All Roslyn analyzers and code-fixers are visible to the user since they are features for the IDE, which is why they always come with some risk. That said, any issues that the fixer and analyzer may have will cause the IDE to automatically turn off the analyzer/fixer as a mitigation. We mainly want to get this out in preview 5 in order to help flush any issues that may exist with it.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

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

[joperezr]

The failures in MSQuic tests are because the snap missed #69798 which disabled those tests. cc: @rzikm @wfurt

[joperezr]

This has been approved via email, so marking this as servicing-approved.

[ericstj]

Test failures are #69792

[danmoseley]

just curious why? RegexGeneratorAttribute allows timeouts.

[joperezr]

I should have added more info into this comment, sorry about that. The main issue here is that Regex constructor and static methods take in a TimeSpan as a timeout argument, but since TimeSpan values are not accepted as attribute parameters, the RegexGeneratorAttribute take int milleseconds instead. I originally did have support and was doing the conversion from TimeSpan -> milliseconds on the fly, but @stephentoub pointed out that this was much more logic than we would ideally want to have in the analyzer, and it could be error prone as we would have to account for a lot of possible cases. For reference, here is what a very similar analyzer is doing to make this conversion so we would basically need to have something similar to this https://github.com/meziantou/Meziantou.Analyzer/blob/b6b41fa2a835fff4dc8cb2a58d692ea1a39f22ab/src/Meziantou.Analyzer/Rules/UseRegexSourceGeneratorAnalyzer.cs#L173-L313

Given it is very rare for folks to even use a timeout to begin with, we opted for now to not emit diagnostics when the call-site has a timeout parameter.