Rename [RegexGenerator] to [GeneratedRegex]

[am11]

Renamed [RegexGenerator] to [GeneratedRegex], updated its usages, renamed analyzer & code fixer, and updated the docs. The internal implementation and some tests use the term RegexGenerator in a few places, which were making less sense when I tried renaming to either GeneratedRegex or GeneratedRegexAttribute, so I have left those files alone.

Closes #62123,

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[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

---

Renamed [RegexGenerator] to [Regex], updated its usages, renamed analyzer & code fixer, and updated the docs. The internal implementation and some tests use the term RegexGenerator in a few places, which were making less sense when I tried renaing to either Regex or RegexAttribute, so I have left those 14 files alone.

Closes #62123,

Author:	am11
Assignees:	-
Labels:	area-System.Text.RegularExpressions, new-api-needs-documentation, community-contribution
Milestone:	-

[am11]

@stephentoub, @joperezr, does it need API review? I have opened it as a Draft in case review is needed.

[teo-tsirpanis]

It almost certainly needs an API review.

[joperezr]

Thanks for opening the PR @am11. Yes, it does require API review, we marked the corresponding issue as blocking to see if we could get to it in today's API Review but we ran out of time. We will likely go over it on Thursday at 10am, if you want to join, they are usually broadcasted live here: https://www.youtube.com/channel/UCiaZbznpWV1o-KLxj8zqR6A

[joperezr]

This PR will also have to update the analyzer and codefixer for the regex source generator:

runtime/src/libraries/System.Text.RegularExpressions/gen/UpgradeToRegexGeneratorAnalyzer.cs

Line 28 in c37f002

private const string RegexGeneratorTypeName = "System.Text.RegularExpressions.RegexGeneratorAttribute";

[am11]

Thanks @joperezr.

This PR will also have to update the analyzer and codefixer

Yup. I updated both in the first commit.

[joperezr]

We discussed this today in APIReview, the decision was to use [GeneratedRegex] instead of [Regex]. @am11 Would you be willing to rename the changes here to match that?

[stephentoub]

Reiterating my comments from API review, runtime libraries flow at a different rate to dependent repos (e.g. dotnet/winforms) than does the generator. I suspect when this merges, we'll end up breaking one or more dependent repos when they try to pick up flowed runtime libraries. We'll end up having a few options I suspect:

• Block updates of the libs until they also pick up a new SDK
• Add GeneratedRegex as a new attribute, update the generator to support both attributes, and then later remove RegexGeneratorAttribute and the support for it once the updated SDK has flown everywhere needed.
• Temporarily undo use of RegexGenerator in dependent repos until they can successfully use GeneratedRegex

I could be wrong, of course. Maybe everything will "just work" 😆

[joperezr]

I agree that this could be problematic. After a quick search in source.dot.net seems like out of the repos where this could cause a problem, only winforms is actively using the attribute. This may or may not be very accurate since source.dot.net isn't a full representation of our repos consumption.

All that said, even though you are right saying that sdk and runtime libraries flow at different rates to these other repos, I'd imagine that the attribute and generator would both be part of the targeting pack, so in theory this shouldn't be a problem if someone is updating their targeting pack that they build against faster than their sdk. In any case, if/when the time comes of a break, I will evaluate the solutions proposed above, and figure out what the best/easiest workaround is. I do very much appreciate the heads up as it is a very valid concern 😄

[stephentoub]

Thanks for working on this.

[joperezr]

I'm seeing that we still have several places where we make reference to "RegexGenerator" in your code, some of them should definitely be changed like:

runtime/src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.cs

Line 49 in 0fbdb1e

// Find all MethodDeclarationSyntax nodes attributed with RegexGenerator and gather the required information.

Some I'm not so sure if we should change, like the actual RegexGenerator generator type or the REGEXGENERATOR constant we use for when building production source. @stephentoub thoughts?

[stephentoub]

Some I'm not so sure if we should change, like the actual RegexGenerator generator type or the REGEXGENERATOR constant we use for when building production source. @stephentoub thoughts?

We shouldn't change those. Those are about the generator.

[am11]

I was looking at the naming convention used by interop generator:

runtime/src/libraries/System.Runtime.InteropServices/gen/LibraryImportGenerator/LibraryImportGenerator.cs

Line 23 in 0fbdb1e

public sealed class LibraryImportGenerator : IIncrementalGenerator

and didn't wanted to use GeneratedRegexGenerator as it is redundant, so I left it as is (RegexGenerator).

[joperezr]

2 very minor comments but looks good otherwise. @am11 would you be able to fix the merge conflicts on the PR? If you need help with this let me know and I'm happy to do so.

[am11]

I have rebased and resolved the merged conflicts. Failures are unrelated network/infra issues.