-
Notifications
You must be signed in to change notification settings - Fork 774
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check provider-sourced pattern
constraints
#16457
base: main
Are you sure you want to change the base?
Conversation
Test this change out locally with the following install scripts (Action run 13509227187) VSCode
Azure CLI
|
Dotnet Test Results 78 files - 39 78 suites - 39 31m 53s ⏱️ - 15m 32s Results for commit 214110b. ± Comparison against base commit 3d03ba0. This pull request removes 1790 and adds 613 tests. Note that renamed tests count towards both.
♻️ This comment has been updated with latest results. |
# Conflicts: # src/Bicep.Core.IntegrationTests/ScenarioTests.cs
// using RegexOptions.ECMAScript for Swagger compatibility. Because this option is | ||
// incompatible with .NET's non-backtracking engine, a timeout is used. | ||
? new Regex(@string.Pattern, RegexOptions.ECMAScript, TimeSpan.FromMilliseconds(100)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unsure if we should be special-casing patterns that come from the az provider. The behavioral differences between standard regexes and the ECMAScript dialect are subtle [0], and I would be surprised if Azure RPs are using the ECMAScript dialect in practice.
Needing to track whether a pattern came from the Az provider types (and thus needs to be interpreted per the ECMAScript dialect) or not (and therefore needs to be interpreted with the standard dialect and non-backtracking engine) adds a fair amount of complexity.
[0]: These would be:
\w
doesn't match alphabetic characters in languages that use non-Latin alphabets- self-referencing capture groups are supported
- the
\
means slightly different things when it's not referring to a capture group
Resolves #15325
Microsoft Reviewers: Open in CodeFlow