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>
As discussed in #1124
A common workflow is running `oxlint` automatically via something like
lint-staged, which passes all changed file paths explicitly as CLI
arguments. The ignore crate auto-whitelists explicit paths, overriding
anything defined in an ignore file, leading to files that should be
ignored causing CI and VC hooks to fail.
eslint avoids this issue by giving precedence to .eslintignore unless
you pass `--no-ignore`.
Since `ignore` doesn't really give much control over this, the most
effective solution seems to be filtering. ~~Once we've got a list of
files to be linted, we can compare each against the .eslintignore and
see if it really truly should be linted.~~
~~Unfortunately, this is sort of a naive solution. Ignored directories
will still be walked, then filtered out after the fact. Changing this
behavior at the walker level would affect the formatter, which probably
isn't desirable.~~ (edit: The performance impact has been mostly
resolved.)
Signed-off-by: Clark Fischer <clark.fischer@gmail.com>
