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