Replace `#[allow]` with `#[expect]` through the whole codebase.
This also surfaced many places where the `#[allow]` attributes were outdated/pointless and could be removed entirely.
Only places `#[allow]` remains are:
1. In generated code and macros, where lint errors may or may not be triggered depending on the generated code.
2. A few places where clippy malfunctions. These use e.g. `#[allow(unused, clippy::allow_attributes)]`.
Preparation for #6141
`oxc_regular_expression` can already parse and validate both `/regexp-literal/` and `new RegExp("string-literal")`.
But one thing that is not well-supported was reporting `Span` for the `RegExp("string-literal-with-\\escape")` case.
For example, these two cases produce the same `RegExp` instances in JavaScript:
- `/\d+/`
- `new RegExp("\\d+")`
For now, mainly in `oxc_linter`, the latter case is parsed with `oxc_parser` -> `ast::literal::StringLiteral` AST node -> `value` property.
At this point, escape sequences are resolved(!), `oxc_regular_expression` can handle aligned `&str` as an argument without any problem in both cases.
However, in terms of `Span` representation, these cases should be handled differently because of the `\\` in string literals...
As a result, the parsed AST's `Span` for `new RegExp("string-literal")` is not accurate if it contains escape sequences.
e.g. https://github.com/oxc-project/oxc/blob/a01a5dfdafb9cd536cb87867697e3ae43b1990e6/crates/oxc_linter/src/snapshots/no_invalid_regexp.snap#L118-L122
Each time the `\` appears, the subsequent position is shifted. `_` should be placed under `*` in this case.
So... to resolve this issue, we need to implement `string_literal_parser` first, and use them as reading units of `oxc_regular_expression`.
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.
- resolves https://github.com/oxc-project/oxc/issues/5977
- supersedes https://github.com/oxc-project/oxc/pull/5951
To facilitate easier traversal of the Regex AST, this PR defines a `Visit` trait with default implementations that will walk the entirety of the Regex AST. Methods in the `Visit` trait can be overridden with custom implementations to do things like analyzing only certain nodes in a regular expression, which will be useful for regex-related `oxc_linter` rules.
In the future, we should consider automatically generating this code as it is very repetitive, but for now a handwritten visitor is sufficient.
- Fix example to handle `new RegExp()` too
- Update NOTE comments
- - -
Until I tried interacting with the actual AST parsed by `oxc_parser`, I thought that the current `oxc_regular_expression` lacked support for the `RegExp` constructor due to escape sequences.
This was because `"\""` remained `"\""` after reading the source text from `.js` files.
However, once it was parsed by `oxc_parser`, I found that everything was [resolved](https://github.com/oxc-project/oxc/blob/8ef85a43c019a1ce9aa50b61ec4dbb5dbaeb3b7b/crates/oxc_parser/src/lexer/string.rs)! (Wonderful work as usual. 👏🏻 )
Now there is nothing to worry about. 😌
Boshen