Coalesce identical constant WordCategories

[IDisposable]

As noted in #84003, there are four places the same mask is computed in this project,. We can't eliminate the one in RegexGenerator.Emitter or its matching unit test because that's outputting the actual C# source string.

In the actual RegexCharClass.cs file changed the name WordCategoriesMask to avoid a conflict with existing member and added as a private constant. I also changed the Emitter and matching unit test to match for neatness.

Removed the detritus in the comments from the copy-paste from Emitter source (trailing " and ,) and fixed the indentation error in the IsWordChar method.

[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

---

There are four places the same mask is computed in this project, can't eliminate the one in RegexGenerator.Emitter or its matching unit test because that's outputting the actual C# source string.

Changed the name WordCategoriesMask to avoid a conflict with existing member and added as a private constant. I changed the Emitter and matching unit test to match for neatness.

Removed the detritus in the comments from the copy-paste from Emitter source (trailing " and ,) and fixed the indentation error in the IsWordChar method.

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

[IDisposable]

A follow-up couple of questions:

• Should we update the emitted code version of IsBoundaryWordChar to inline the IsWordChar body like is done in RegexCharClass? It currently emits IsWordChar(ch) || (ch == '\\u200C' | ch == '\\u200D');
• In the emitted version, we're asking for $"[MethodImpl(MethodImplOptions.AggressiveInlining)]"... would we eventually want to do the same on the RegexCharClass versions of either or both methods?

[stephentoub]

Should we update the emitted code version of IsBoundaryWordChar to inline the IsWordChar body like is done in RegexCharClass? It currently emits IsWordChar(ch) || (ch == '\u200C' | ch == '\u200D');

We did it this way to avoid code bloat with the code emitted into every assembly that uses it. If we hear of an issue with this, we can revisit, but I'm not aware of any. ECMA word boundaries are rare.

In the emitted version, we're asking for $"[MethodImpl(MethodImplOptions.AggressiveInlining)]"... would we eventually want to do the same on the RegexCharClass versions of either or both methods?

Only if it proves impactful.