Using `NonZeroUsize` lets `rustc` detect a niche value, shrinking the size of `CacheStateEntry` from 16 bytes to 8. It has the added benefit of making `CacheStateEntry::PendingStore`'s purpose clearer.
This will make it easier to review PRs in github codespaces.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
> Closes#5046
This PR migrates the linter crate and oxlint app to use the new `LinterBuilder` API. This PR has the following effects:
1. `plugins` in oxlint config files are now supported
2. irons out weirdness when using CLI args and config files together. CLI args are now always applied on top of config file settings, overriding them.
# Breaking Changes
Before, config files would override rules set in CLI arguments. For example, running this command:
```sh
oxlint -A correctness -c oxlintrc.json
```
With this config file
```jsonc
// oxlintrc.json
{
"rules": {
"no-const-assign": "error"
}
}
```
Would result in a single rule, `no-const-assign` being turned on at an error level with all other rules disabled (i.e. set to "allow").
Now, **CLI arguments will override config files**. That same command with the same config file will result with **all rules being disabled**.
## Details
For a more in-depth explanation, assume we are running the below command using the `oxlintrc.json` file above:
```sh
oxlint -A all -W correctness -A all -W suspicious -c oxlintrc.json
```
### Before
> Note: GitHub doesn't seem to like deeply nested lists. Apologies for the formatting.
Here was the config resolution process _before_ this PR:
<details><summary>Before Steps</summary>
1. Start with a default set of filters (["correctness", "warn"]) if no filters were passed to the CLI. Since some were, the filter list starts out empty.
2. Apply each filter taken from the CLI from left to right. When a filter allows a rule or category, it clears the configured set of rules. So applying those filters looks like this
a. start with an empty list `[]`
b. `("all", "allow")` -> `[]`
c. `("correctness", "warn")` -> `[ <correctness rules> ]`
d. `("all", "allow")` -> `[]`
e. `("suspicious", "warn")` -> `[ <suspicious rules> ]`. This is the final rule set for this step
3. Apply overrides from `oxlintrc.json`. This is where things get a little funky, as mentioned in point 2 of what this PR does. At this point, all rules in the rules list are only from the CLI.
a. If a rule is only set in the CLI and is not present in the config file, there's no effect
b. If a rule is in the config file but not the CLI, it gets inserted into the list.
c. If a rule is already in the list and in the config file
i. If the rule is only present once (e.g. `"no-loss-of-precision": "error"`), unconditionally override whatever was in the CLI with what was set in the config file
ii. If the rule is present twice (e.g. `"no-loss-of-precision": "off", "@typescript-eslint/no-loss-of-precision": "error"`),
a. if all rules in the config file are set to `allow`, then turn the rule off
b. If one of them is `warn` or `deny`, then update the currently-set rule's config object, but _leave its severity alone_.
So, for our example, the final rule set would be `[<all suspicious rules: "warn">, no-const-assign: "error"]`
</details>
### After
Rule filters were completely re-worked in a previous PR. Now, lint filters aren't kept on hand-only the rule list is.
<details><summary>After Steps</summary>
1. Start with the default rule set, which is all correctness rules for all enabled plugins (`[<all correctness rules: "warn">]`)
2. Apply configuration from `oxlintrc.json` _first_.
a. If the rule is warn/deny exists in the list already, update its severity and config object. If it's not in the list, add it.
b. If the rule is set to allow, remove it from the list.
The list is now `[<all correctness rules except no-const-assign: "warn">, no-const-assign: "error"]`.
3. Apply each filter taken from the CLI from left to right. This works the same way as before. So, after they're applied, the list is now `[<suspicous rules: "warn">]`
</details>
closes#6227
I noticed that the implementation of `collapse-variable-declarations`
seems incomplete and appears quite simple. Therefore, I would like to
quickly add all the test cases to work on this.
Previously, I saw that `DonIsaac` had also submitted a related PR, but
he might have been too busy to respond for a long time. I want to
apologize for closing his PR.
Fixes several false positive cases for referenced variables and declarations
that are inside type casts, `as` expressions, `satisfies` expressions, non-null
assertions, and the like.
```js
function foo(el) { return el + 1 }
const arr = [1, 2, 3]
const mapped = arr.map(foo as unknown as SomePredicateType)
```
Fixes a false positive in `eslint/no-unused-vars` when a function expression is
default exported within an array.
```js
export default [ function foo() {} ]
```
Fixes a false positive when a function or class expression is an array element.
Found while linting Jest tests in an internal repo.
```js
import { stringify } from './custom-stringify';
test.each(['a', 1, function foo() {}])('When stringifying %p, matches the snapshot', input => {
expect(stringify(input)).toMatchSnapshot();
})
```
closes#6382
It seems we cannot support `oxc_language_server` by directly reusing
code from `coc-oxc`, at least not on Windows, because it requires an
`.exe` executable.
I will take some time to study the implementation of `Biome` to enhance
our vscode plugin.
Implements naive suggestions for the `no-plusplus` rule. This is not implemented as a fix, because there isn't an exact 1:1 equivalence between `++` and `+= 1`. But most cases should be autofixable by this, but I've marked it as dangerous suggestion due to the semantics change
