## Why
Due to the usage of `&'alloc mut T` in `oxc_allocator::Box`, and
`bumpalo::collections::Vec` in `oxc_allocator::Vec`, ast types are
currently invariant over their allocator lifetime `'a`. This prevents
`ouroboros` from generating `borrow_*` on ast type fields, leading to
the unfriendly `with_*` api:
c250b288ef/crates/oxc_parser/examples/multi-thread.rs (L82-L84)
## How
- For `oxc_allocator::Vec`, switch to `allocator_api2::vec::Vec`, which
has a covariant relationship with the allocator lifetime.
- For `oxc_allocator::Box`, use `std::ptr::NonNull` which is
specifically designed to be covariant. I don't use
`allocator_api2::boxed::Box` because it holds the allocator for
dropping, so the size is bigger.
## Downside
Now that `oxc_allocator::Box` uses the unsafe `NonNull`. It has to be a
private field to be safe. This make it impossible to do `Box(....)`
pattern matching.
Fixes#2936
*personally* I think it's best if all of the `_ => {}` match cases were
removed from the codebase so that things are provably exhaustive.
This does exactly that specifically for `walk_ts_type` - filling in the
missing cases and all the required code for them.
> The error message emphasizes "empty text" so I would put the span on
the extra text.
> https://github.com/oxc-project/oxc/pull/2893#discussion_r1548843621
To address this, special `Span` handling should be implemented for
comment part.
So, this PR introduces:
- `JSDocCommentPart` struct holds raw `.span` and special
`.span_trimmed_first_line()`
- Add `JSDocKindPart`, `JSDocTypePart` and `JSDocTypeNamePart` in the
same manner
- `JSDocTag` uses these depending on the purpose
For milestone 1, I think it's safe to just layout all the
transformations manually.
In TypeScript, the transformers are collected dynamically and ran on
each ast node; this achieves a single AST pass.
https://github.com/microsoft/TypeScript/blob/main/src/compiler/transformer.ts#L129-L145
To maximize performance and reduce confusion, I think it's safe to
layout all the transformations manually for milestone 1.
The next PR will add transformation context to all presets so we can
start adding "context".
A fix for the work done in: https://github.com/oxc-project/oxc/pull/2905
The existing code checks if _all_ import entries in a ModuleRecord are
type-only, when determining if the ModuleRecord should be skipped when
checking for cycles. This is incorrect.
To demonstrate the problem: Running the `no-cycles` rule, with
`ignoreTypes` enabled, on the following example code will cause a cycle
to be reported between Module A and Module B
```typescript
// Module A
import type { Bar } from './b';
import { Baz } from './c'
// Module B
import type { Foo } from './a';
// Module C
export const Baz = 'baz';
```
The reason this is happening is because the import to Module C in Module
A is causing the `was_imported_as_type` variable to evaluate to `false`,
since the Module C import is not type-only.
What we actually want to do is skip visiting Module B entirely, by
checking if its import request from Module A is type-only.
This PR fixes the logic so that only the import entries for the next
ModuleRecord are considered when determining `was_imported_as_type`.
The flakiness and all the noise produced by it is starting to hurt
maintenance because I can no longer tell if main or PR is failing
properly :-(
codspeed doesn't have the feature "let it run but don't report as error"
or "different thresholds on different benchmarks"
Fixes umbrella issue for
[`plugin-jest`](https://github.com/oxc-project/oxc/issues/492) to render
recommended rules section properly.
- - -
Along with sticking legacy ESLint.
Since `eslint@latest` is now v9 and it removed `Linter#defineRule()` and
`Linter#getRules()` which we use heavily...
Added tests to figure out what the problem from the issue was and
realize the self closing tag was not expected. Added code to handle this
case.
I am not that familiar with astro to know how common self closing script
tags are, their docs seem to use an opening and closing one for inline
scripts
https://docs.astro.build/en/guides/client-side-scripts/#load-external-scripts
While looking into this, I knew vue would have similar problems. Which
then led me to realize the generic case was handled already so I tried
abstract out the function so both the vue and svelte partial loaders
could reuse the code. Finally added some svelte test cases to prove this
resolved the issue.
I am a bit new to rust so if there was a better way to reuse the
find_script_closing_angle function open to suggestions.
