`Stack` is a stack structure, optimized for fast push/pop and reading/writing the last entry on the stack. The difference from `NonEmptyStack` is that it can be empty.
This has a different trade-off vs `NonEmptyStack`:
* `Stack::new` does not allocate (`NonEmptyStack` does).
* `Stack::last` and `Stack::last_mut` are fallible and contain a branch (those methods on `NonEmptyStack` are branchless and infallible).
`Stack` is only the better choice if:
1. You want `new()` not to allocate. or
2. Creating initial value for `NonEmptyStack::new()` is expensive.
Use `Stack` as one of the backing stores in `SparseStack`.
`NonEmptyStack` is a stack structure, optimized for fast push/pop and reading/writing the last entry on the stack. By always having 1 at least one entry, `last` and `last_mut` can be made branchless and extremely cheap (only 1 CPU op).
Use `NonEmptyStack` as one of the backing stores in `SparseStack`.
Fixes a bug where rules for a plugin are still added to the linter after that plugin gets disabled.
```rust
// `linter` still has typescript-eslint rules. This PR fixes that.
let linter = LinterBuilder::default()
.and_plugins(LintPlugins::TYPESCRIPT, false)
.build();
```
> AI generated because I'm busy
### TL;DR
Enhanced LinterBuilder functionality and improved rule configuration handling.
### What changed?
- Made `rules` field in `LinterBuilder` public within the crate.
- Added a `plugins()` method to `LinterBuilder` to access lint plugins.
- Improved rule configuration logic in `configure_rules` method to update existing rules' severity.
- Added comprehensive test cases for `LinterBuilder` functionality.
- Implemented `Borrow<RuleEnum>` for `RuleWithSeverity` to improve rule lookup efficiency.
### How to test?
1. Run the newly added test cases in the `test` module of `builder.rs`.
2. Verify that all tests pass, including:
- Default builder configuration
- Empty builder configuration
- Rule filtering and severity changes
- Plugin configuration and rule interactions
### Why make this change?
These changes improve the flexibility and robustness of the linter configuration process:
1. Allowing access to the `rules` field enables more advanced customization options.
2. The new `plugins()` method provides better visibility into configured plugins.
3. Updating existing rules' severity ensures consistent behavior when reconfiguring rules.
4. Comprehensive tests ensure the reliability of the `LinterBuilder` functionality.
5. Implementing `Borrow<RuleEnum>` for `RuleWithSeverity` optimizes rule lookup operations.
These enhancements contribute to a more maintainable and efficient linter system.
- resolves https://github.com/oxc-project/oxc/issues/5977
- supersedes https://github.com/oxc-project/oxc/pull/5951
To facilitate easier traversal of the Regex AST, this PR defines a `Visit` trait with default implementations that will walk the entirety of the Regex AST. Methods in the `Visit` trait can be overridden with custom implementations to do things like analyzing only certain nodes in a regular expression, which will be useful for regex-related `oxc_linter` rules.
In the future, we should consider automatically generating this code as it is very repetitive, but for now a handwritten visitor is sufficient.
# What This PR Does
Enhance's `oxc_semantic`'s integration tests with a regression test suite that ensures semantic's contract guarantees hold over all test cases in typescript-eslint's scope snapshot tests. Each test case checks a separate assumption and runs independently from other test cases.
This PR sets up the code infrastructure for this test suite and adds two test cases to start us off:
1. Reflexivity tests for `IdentifierReference` and `Reference`
2. Symbol declaration reflexivity tests between declarations in `SymbolTable` and their corresponding node in the AST.
Please refer to the doc comments for each of these tests for an in-depth explanation.
## Aren't our existing tests sufficient?
`oxc_semantic` is currently tested directly via
1. scope snapshot tests, ported from `typescript-eslint`
2. Hand-written tests using `SemanticTester` in `tests/integration`
And indirectly via
3. Conformance test suite over Test262/TypeScript/Babel
4. Linter snapshot tests
Shouldn't this be sufficient? I argue not, for two reasons:
## 1. Clarify Contract Ambiguity
When using `Semantic`, I often find myself asking these questions?
* Does `semantic.symbols().get_declaration(id)` point to a `BindingIdentifer`/`BindingPattern` or the declaration that holds an identifier/pattern?
* Will a `Reference`'s `node_id` point me to an `IdentifierReference` or the expression/statement that is holding an `IdentifierReference`?
* When will `BindingIdentifier`'s `symbol_id` get populated? can we guarantee that after semantic analysis it will never be `None`?
* What actually _is_ the node covered by `semantic.symbols().get_span(id)`? This one really messed me up, and resulted in me creating #4739.
* What scope does `Function::scope_id` point to? The one where the function is declared? The one created by its body? The one created by the type annotations but before the function body? Or something else entirely?
**These test cases are meant to answer such questions and guarnatee those answers as test cases**. No other existing testing solution currently upholds such promises: they only tell us if code expecting one answer or another produces an unexpected result. However, those parts of the codebase could always be adjusted to conform to new `Semantic` behavior, meaning no contract guarantees are actually upheld.
## 2. Existing Tests Do Not Test The Same Behavior
I'll cover each above listed test case one-by-one:
1. For starters, these tests only cover scopes. Additionally, they only tell us **how behavior has changed**, not that **behavior is now incorrect**.
2. These _do_ generally cover the same behaviors, but **are not comprehensive and are difficult to maintain**. These are unit tests that should be used hand-in-hand with this new test suite.
3. The most relevant tests here are for the parser. However, these tests **only tell us if a syntax/parse error was produced**, and tell us nothing about the validity of `Semantic`.
4. Relying on lint rule's output is a a mediiocre proxy of `Semantic`'s behavior at best. They can tell us if changes to `Semantic` break assumptions made by lint rules, but they do not tell us if **those assumptions are the ones we want to uphold to external crates consuming `Semantic`.
Fixes https://github.com/oxc-project/oxc/issues/6046
Unlike other escape sequences such as `/\w/`, this is not actually parsed as a single character: `/\c/` so we incorrectly try to get the character before the backslash, which doesn't exist.
- there can not be an `UnaryExpression` as a `parent_kind`, when the
`ast_kind` is `NumericLiteral`,
`InternConfig::from` prevents it from happending
- `NumericLiteral` can not be negative or else they would be passed as
`UnaryExpression`
In the previous PR, I added an additional span that allows us to actually point to the prior hook function that the hook should be moved above. I've updated the error messages to hopefully be a little bit more helpful in explaining what to do.
Profiling this in a single-threaded run showed this rule to be relatively slow compared to other rules:
<img width="907" alt="image" src="https://github.com/user-attachments/assets/789cdc1f-d1ce-4d4a-bfa3-5882bd92cfc4">
The profile shows that a lot of time is spent doing pushes on `Vec`:
<img width="896" alt="image" src="https://github.com/user-attachments/assets/cde361d7-091d-42db-abc2-76a0c8a7fa44">
I believe this is because we were essentially duplicating the entirety of `ctx.nodes()`, and then iterating over it again for the actual rule.
I addressed this by:
- We no longer store any nodes (we only store the previous hook span + order), which saves many allocations.
- We only iterate over the nodes once and store the previous hook function in a per-scope hash map. This should be faster since we now only do `n` iterations, instead of `2n` iterations.
Benchmarking on the `microsoft/vscode` repository shows that this is probably faster (by up to ~3%), and probably not any slower:
<img width="992" alt="Screenshot 2024-09-24 at 12 06 32 PM" src="https://github.com/user-attachments/assets/ab916464-1b50-48e1-a65d-f9b3a4b4607d">
The snapshot change in this PR is due to slightly different ordering, I think, but it appears to be the same diagnostics overall.
Fixes a bug in `eslint/no-unexpected-multiline` where newlines in
function call type parameters triggered a false positive. For example:
```ts
const foo = bar<{
a: string
b: number
}>();
```
