Fix#7254
Changed all "raw" properties of literal types (if they have this property) to `Option<Atom>`.
---------
Co-authored-by: overlookmotel <theoverlookmotel@gmail.com>
This has the benefit of:
* expose dynamic import / import meta info from parser
* 1 less ast shallow in semantic builder
* no ast walk in oxc's module lexer
* some more benefits coming soon
Adds some new estree macro directives:
- `#[estree(via = foo::Foo)`: Uses From to convert this struct to foo::Foo before serialization
- `#[estree(add_ts = "foo: string")]`: Adds additional fields to the typescript definitions
Used these to make all different literals estree-compatible.
Preparation for #7073. Avoid using `AstBuilder::*_from_*` methods to construct enums, use explicit construction instead.
Before:
```rs
let ident = self.ast.binding_pattern_kind_from_binding_identifier(ident);
```
After:
```rs
let ident = BindingPatternKind::BindingIdentifier(ident);
```
Often this produces shorter code, as well as (in my opinion) being easier to read.
Pure refactor. Introduce `ParserImpl::alloc` method. Shorten `self.ast.alloc(...)` to `self.alloc(...)`.
Also reduce `alloc` calls by using `AstBuilder` methods which already allocate where possible.
## What This PR Does
Provide better error messages when a reserved word is used as a `BindingIdentifier`
```ts
var const = 1;
export enum const {}
const if = 1;
```
Quality-of-life improvement for invalid `const` modifiers on class elements. Instead of panicking, the parser will eat `const` and report it as an error.
```ts
class C {
static const H = 1;
}
```
I intend to add constant folding and eval logic to this crate. There are downstream tools that require these functionalities alone.
It's also reasonable to move these traits out of the `ast` crate.
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.
Closes#5736.
Introduce a `NONE` type which can be used for any `AstBuilder` method call param which expects an `IntoIn<'a, Something<'a>>`, where otherwise you have to provide a verbose type annotation.
Before:
```rs
ast.arrow_function_expression(
SPAN,
is_expression,
is_async,
None::<TSTypeParameterDeclaration>,
params,
None::<TSTypeAnnotation>,
body,
)
```
After:
```rs
ast.arrow_function_expression(SPAN, is_expression, is_async, NONE, params, NONE, body)
```
See https://babel.dev/docs/options#misc-options for background on `unambiguous`
Once `SourceType::Unambiguous` is parsed, it will correctly set the returned `Program::source_type` to either `module` or `script`.
Closes#5177
While making this, I noticed an uncaught parse error for accessors: accessors cannot be optional. I'll add a fix for this in an up-stack PR.
