-
-
Notifications
You must be signed in to change notification settings - Fork 781
refactor(ast, regular_expression)!: converge oxc_ast::RegExpFlags and oxc_regular_expression::ast::Flags.
#5592
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
Conversation
Your org has enabled the Graphite merge queue for merging into mainAdd the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix. You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link. |
This stack of pull requests is managed by Graphite. Learn more about stacking. |
dd1e537 to
9e157cb
Compare
oxc_ast::RegExpFlags and oxc_regular_expression::ast::Flags.oxc_ast::RegExpFlags and oxc_regular_expression::ast::Flags.
CodSpeed Performance ReportMerging #5592 will not alter performanceComparing Summary
|
…d `oxc_regular_expression::ast::Flags`.
9e157cb to
4d8d090
Compare
|
|
||
| #[cfg(feature = "serialize")] | ||
| #[wasm_bindgen::prelude::wasm_bindgen(typescript_custom_section)] | ||
| const TS_APPEND_CONTENT: &'static str = r#" |
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.
Should I change any javascript code now that this binding is renamed?
| pub fn with_unicode_sets_mode(self) -> ParserOptions { | ||
| ParserOptions { unicode_mode: true, unicode_sets_mode: true, ..self } | ||
| pub fn with_flags(self, flags: RegularExpressionFlags) -> Self { | ||
| Self { flags, ..self } |
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 prefer this in order to split the domain more explicit. 👀
| Self { flags, ..self } | |
| Self { | |
| unicode_mode: flags.intersects(RegularExpressionFlags::U | RegularExpressionFlags::V), | |
| unicode_sets_mode: flags.contains(RegularExpressionFlags::V), | |
| ..self | |
| } |
This PR makes 2 changes to improve the existing API that are not very useful.
- Remove `(Literal)Parser` and `FlagsParser` and their ASTs
- Add `with_flags(flags_text)` helper to `ParserOptions`
Here are the details.
> Remove `(Literal)Parser` and `FlagsParser` and their ASTs
Previously, the `oxc_regular_expression` crate exposed 3 parsers.
- `(Literal)Parser`: assumes `/pattern/flags` format
- `PatternParser`: assumes `pattern` part only
- `FlagsParser`: assumes `flags` part only
However, it turns out that in actual usecases, only the `PatternParser` is actually sufficient, as the pattern and flags are validated and sliced in advance on the `oxc_parser` side.
The current usecase for `(Literal)Parser` is mostly for internal testing.
There were also some misuses of `(Literal)Parser` that restore `format!("/{pattern}/{flags}")` back and use `(Literal)Parser`.
Therefore, only `PatternParser` is now published, and unnecessary ASTs have been removed.
(This also obsoletes #5592 .)
> Added `with_flags(flags_text)` helper to `ParserOptions`
Strictly speaking, there was a subtle difference between the "flag" strings that users were aware of and the "mode" recognised by the parser.
Therefore, it was a common mistake to forget to enable `unicode_mode` when using the `v` flag.
With this helper, crate users no longer need to distinguish between flags and modes.
|
Closing, |

closes #5562