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.
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.
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