## 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"
