Repository navigation
[release/9.0-staging] Use invariant culture when formatting transfer capture in regex source generator (#113081) - #113150
Conversation
Sorry, something went wrong.
…e generator (dotnet#113081) A balancing group can result in TransferCapture being emitted with a negative "capnum". If the compiler is running under a culture that uses something other than '-' as the negative sign, the resulting generated code will fail to compile.
There was a problem hiding this comment.
PR Overview
This pull request backports a fix to ensure that regex source generation uses invariant culture for formatting transfer capture values. The key changes include updating the test helper to run under a modified culture with a non-standard negative sign and modifying the regex emitter to explicitly format numeric values with CultureInfo.InvariantCulture.
- Added a custom CultureInfo in test code to simulate cultures with a non-standard negative sign.
- Updated the generator driver block to temporarily set the current culture during regex generation.
- Modified the numeric formatting in RegexGenerator.Emitter.cs to use CultureInfo.InvariantCulture.
Reviewed Changes
| File | Description |
|---|---|
| src/libraries/System.Text.RegularExpressions/tests/FunctionalTests/RegexGeneratorHelper.netcoreapp.cs | Added test culture and updated generator culture handling. |
| src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.Emitter.cs | Updated numeric formatting for transfer capture to use invariant culture. |
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
Comments suppressed due to low confidence (2)src/libraries/System.Text.RegularExpressions/tests/FunctionalTests/RegexGeneratorHelper.netcoreapp.cs:137
- Constructing a CultureInfo with an empty string may lead to unexpected behavior; consider basing it on a known culture (e.g., CultureInfo.InvariantCulture) and then modifying its NumberFormat to ensure predictable testing.
private static readonly CultureInfo s_cultureWithMinusNegativeSign = new CultureInfo("")
src/libraries/System.Text.RegularExpressions/gen/RegexGenerator.Emitter.cs:2552
- This change correctly enforces invariant culture formatting for capnum; verify that similar formatting safeguards are in place for other numerical values where culture-specific formatting may cause issues.
writer.WriteLine($"base.TransferCapture({capnum.ToString(CultureInfo.InvariantCulture)}, {uncapnum}, {startingPos}, pos);");
Tip: Copilot only keeps its highest confidence comments to reduce noise and keep you focused. Learn more
Sorry, something went wrong.
|
Tagging subscribers to this area: @dotnet/area-system-text-regularexpressions |
Sorry, something went wrong.
|
/ba-g test failures are unrelated |
Sorry, something went wrong.
Backport of #113081 to release/9.0-staging
/cc @stephentoub
Customer Impact
Using the regex source generator with certain patterns (any containing a "balancing group") will cause the containing project to fail to build when compiling on a system where the culture uses something other than '-' as a negative sign. ~10% of cultures in CultureInfo.GetCultures fit this category. For example, if you try to compile this:
on a system in Sweden, it is likely to fail to build.
Regression
Testing
Updated the test suite to run source generator tests in such a culture.
Risk
Low. It's changing how a single number is rendered, using the invariant culture rather than the current culture. The new code will succeed in all the places the old code did, and where the old code failed, it would fail to compile.