This was incorrectly using raw for dynamically generated numbers like in
the minifier (
6e0bd52af1/crates/oxc_minifier/src/compressor/fold.rs (L280)
).
This ensures they are dynamically generated during codegen.
This does not investigate why `just example minifier` does not take the
`if MINIFY` branch.
---------
Co-authored-by: Boshen <boshenc@gmail.com>
This PR is part of #1880.
`Token` size is reduced from 48 to 40 bytes.
To reconstruct the regex pattern and flags within the parser , the regex
string is
re-parsed from the end by reading all valid flags.
In order to make things work nicely, the lexer will no longer recover
from a invalid regex.
This PR partially fixes#1803 and is part of #1880.
BigInt is removed from the `Token` value, so that the token size can be
reduced once we removed all the variants.
`Token` is now also `Copy`, which removes all the `clone` and `drop`
calls.
This yields 5% performance improvement for the parser.
1. Use `log::info` to print some informantion which we would want to
display in release mode,
2. Add config to switch back `debug` log level in development mode.
Partially address #1879
See there for more info. but tldr:
Printing a lot of diagnostics takes a lot of time - a lot longer than it
takes to create them
we speed up printing by producing less diagnostics.
we do this by making `no-sparse-arrays` report 1x per array instead of
1x per violation.
This does have the overhead of now every ArrayElement is processed 2x
(1x when we loop through in the rule, 1x when we loop through the ast).
But the perf reduction is negligble compared to the per production of
producing thousands of diagnostics vs 1 diagnostic.
This means that linting nodejs/node now takes ~1.5 seconds vs ~2:30
previously
it was builded a loop that iterates in trivias.irregular-whitespace and
return the warning if contain some specific sequence of chars.
---------
Co-authored-by: Boshen <boshenc@gmail.com>
Parser incorrectly identifies string literals as directives if they
follow after `import`s, `export`s, or decorators.
In all of these cases, `'use strict'` produces a directive in the AST,
where it should be parsed as an `ExpressionStatement` containing a
`StringLiteral`:
```js
import x from 'foo';
'use strict';
```
```js
export {x};
'use strict';
```
```js
@foo
'use strict';
```
[Playground](https://oxc-project.github.io/oxc/playground/?code=3YCAAIC0gICAgICAgIC0G8rnONK89ITJ3zrK%2FUP7OmSZPgHQzStr3yMtwFTU%2BD1WPt09JgqZJLoYooydbGsM5vGcf34BnIA%3D)
This PR should fix that.
I'm not sure about the decorator case, though. I assume it's not a
directive. But is prefixing a string literal with a decorator even legal
syntax anyway?
And a side nit: If I'm reading it right, I don't think the `continue`
statement in the decorator arm of the match does anything. Do I have
that right?
Last question: Where does one go about putting a test? I guess these
silly cases aren't covered by Babel etc's tests.
---------
Co-authored-by: Boshen <boshenc@gmail.com>
