## 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`.
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.
# What This PR Does
Symbols declared inside exported functions and classes were being
incorrectly flagged with `SymbolFlags::Export`.
For example,
```ts
export function foo<T>(a: T) {
let b = String(a)
return b
}
```
`T`, `a`, and `b` were all flagged as exported.
## Further Work
It doesn't seem like exported enums and interfaces are being included in
`ModuleRecord`. Am I looking in the wrong place, or are they actually
missing?
