I thought I was being clever, but too clever = stupid.
The dummy code designed to flag when our MSRV is bumped and supports `NonNull::add` would fail to compile on Rust versions below 1.80.0. Precisely because of the condition this code is testing - it's not supported!
Fix this by skipping compilation unless running clippy.
- closes#6459
Currently, the `unicorn/filename-case` doesn't match the behavior of the original rule. There are several issues which this PR fixes:
- The defaults cases were incorrect: only kebab case should be enabled by default, according to the original rule docs.
- Setting a single case or multiple cases did not remove the default cases as it should.
- Leading/trailing underscores were not ignored by default.
- We did not provide a clear diagnostic message indicating which cases are allowed.
- We did not try to parse out multiple file parts (separated by `.`).
- TODO: We should also support multiple file part checking (which the original rule supports via a config option), for file names such as `someTest.fileName.js`
I have also added many of the original test cases to ensure we are more closely compatible.
This also improves the performance of just running the `unicorn/filename-case` alone by 4% (20ms total) on the `vscode` codebase:
```
Benchmark 1: ./oxlint-main -A all -W unicorn/filename-case --silent vscode
Time (mean ± σ): 489.4 ms ± 24.0 ms [User: 2623.8 ms, System: 447.2 ms]
Range (min … max): 474.7 ms … 622.9 ms 100 runs
Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
Benchmark 2: ./oxlint-new-filename-case -A all -W unicorn/filename-case --silent vscode
Time (mean ± σ): 470.8 ms ± 22.9 ms [User: 2478.8 ms, System: 463.5 ms]
Range (min … max): 455.6 ms … 599.3 ms 100 runs
Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
Summary
./oxlint-new-filename-case -A all -W unicorn/filename-case --silent vscode ran
1.04 ± 0.07 times faster than ./oxlint-main -A all -W unicorn/filename-case --silent vscode
```
Perplexingly, it seems like it might actually be even faster on the `vscode` repository, saving ~5% (70ms) with the default ruleset enabled as well. Maybe my laptop was just running a bit faster.
```
Benchmark 1: ./oxlint-main -W unicorn/filename-case --silent vscode
Time (mean ± σ): 1.402 s ± 0.096 s [User: 8.863 s, System: 0.505 s]
Range (min … max): 1.318 s … 1.920 s 100 runs
Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
Benchmark 2: ./oxlint-new-filename-case -W unicorn/filename-case --silent vscode
Time (mean ± σ): 1.339 s ± 0.042 s [User: 8.582 s, System: 0.511 s]
Range (min … max): 1.266 s … 1.506 s 100 runs
Summary
./oxlint-new-filename-case -W unicorn/filename-case --silent vscode ran
1.05 ± 0.08 times faster than ./oxlint-main -W unicorn/filename-case --silent vscode
```
Profiling showed that this rule was one of the slower ones, partially due to the fact that it was constantly calling `ctx.nodes()` and `ctx.nodes().parent_node()`. I've tried to fix this by reordering the logic so that we only fetch the parent nodes right before we need it. If we can early return, such as the identifier name not being `innerText`, or the node kind not being right, then we can skip fetching the parent.
Before:
<img width="1147" alt="Screenshot 2024-10-12 at 3 05 05 AM" src="https://github.com/user-attachments/assets/4a551b04-370f-4ed9-b0d5-99d58b03235b">
After (-0.4% reduction in number of samples spent in this rule):
<img width="1146" alt="image" src="https://github.com/user-attachments/assets/340edc36-55cc-4bf4-aa8e-9a600848b798">
# What This PR Does
Adds `CodeBuffer`, a simple wrapper over a `Vec<u8>` with a protective and reduced API for upholding UTF-8 validity guarantees. Closes#6147.
Note that this struct is actually quite small. Most of the added lines are doc comments.
Support import like `import React from 'react';` by `ModuleImports`
The usage is:
```rs
self.ctx.module_imports.add_import(
Atom::from("react"),
ImportKind::new_default(Atom::from("React")),
symbol_id
)
close: #6385
The fixing way was referenced from `esbuild`, it is according to these [states](332727499e/internal/js_ast/js_ast.go (L590-L604)
)(determined in the parser) to determine whether to print parenthesis
Due to differences in implementation details, we are unable to record certain information like `esbuild` does in its parser. But fortunately, The `ParenthesisExpression` AST is actually like what `esbuild` stored states.
Previous PR removed the Prettier commands
(https://github.com/oxc-project/oxc/pull/6412), but the prettier
dependency was not fully removed. This PR aims to remove the dependency
from package.json entirely.
---------
Co-authored-by: Boshen <boshenc@gmail.com>
## What This PR Does
1. Recover on, and provide a better message for, invalid `export` modifier on constructor parameters. Before, an `unexpected token` error would be produced and the parser would panic. Now, the parser recovers and produces a message saying `'export' modifier cannot appear on a parameter.`
```ts
class Foo {
constructor(export x: number) {}
}
```
2. Recover on, and provide a better message for, invalid modifiers on index signatures. Same recovery/message characteristics as above.
```ts
class Foo {
public [x: string]: string;
}
```
## 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;
```
