feat(transformer-dts): report error for async function and generator
fix(transformer-dts): correct span for type containing private name error
fix(transformer-dts): should add reference for export specifiers
This PR implements namespace transform:
Look at this example
```ts
let internal = 0;
export namespace ns {
namespace internal {
export class Foo {}
}
export namespace nested {
export import inner = internal;
}
}
// to
export declare namespace ns {
namespace internal {
class Foo {
}
}
export namespace nested {
export import inner = internal;
}
export {};
}
```
The `let internal = 0` is unexported, and is unreferenced in other types. So we need to remove it.
I refactored `scope` because the previous implementation could not correctly remove unexported and unreferenced declarations.
For example, in this case
```ts
type T = string;
export function foo<T>(): T {
}
// to
type T = string;
export declare function foo<T>(): T;
```
The `type T = string` should be deleted, Because the `T` is not used in the function return type.
```ts
function hello<T>(a: T): T {
return 0 as T
}
```
The `T` is a type parameter. It can be used in `FormalParameters`, `ReturnType`, and `FunctionBody`. Therefore we need to visit `type_parameters` before visiting `FormalParameters`, `ReturnType`, and `FunctionBody`
closes#621
[no-unreachable](069aa680c7/lib/rules/no-unreachable.js (L196))
[oxlint-echosystem-ci result](https://github.com/rzvxa/oxlint-ecosystem-ci/actions/runs/9406195143/job/25909079029)
This rule is done but since it is running for every possible statement and does quite a bit of work on them to determine whether it is 100% reachable or not; The performance in my opinion is kind of abysmal.
I'll try to work it out, I know Biome does 2 types of checks to simplify the rule for some nodes, However, they have a lot more false negatives than our implementation.
##### Here is one example of those [false negatives](https://biomejs.dev/playground/?code=ZgB1AG4AYwB0AGkAbwBuACAAeAAoACkAIAB7ACAAZABvACAAewAgAGEAKAApADsAIAB9ACAAdwBoAGkAbABlACgAdAByAHUAZQApADsAIABiACgAKQA7ACAAfQA%3D)
-------------
### Update 1:
I've benchmarked this rule using only the simplified reachability checks and it was around 5% faster, To be honest, it isn't much improvement especially considering that we can only use this check for a small portion of nodes and even that is accompanied by newly introduced checks which would lessen the amount of performance gain further.
Most of the performance regression is because of allocations during our depth first search since we have to store both the visited and finished nodes which results in a bunch of rapid-fire allocations back to back. Currently, At the moment I don't have a great idea of how to improve it, We may have to implement our own graph to use arenas underneath.
Given that this rule is the most extensive use case of control flow (It doesn't come with a limited scope similar to property and constructor rules already implemented) this performance drop might be reasonable to some extent.
------------
### Update 2:
I reworked my approach in 2 senses, First I used @Boshen's suggestion inspired by TypeScript and kept some of the reachability information in the basic block structure instead of calculating it on the fly. It is done by propagating the `Unreachable` edge and `Unreachable` instruction throughout subgraphs.
This for sure helped with the performance but the next part is what never failed to amaze me, Going from something near `O(n!)` in the worst-case scenario to `O(n^2)` (in the worst-case scenario). By changing the approach instead of checking the reachability of each statement we do it in 3 paths; First, we do a path on the entire CFG and query all reachable but suspicious cases, and then we do another path on each of these suspicions subgraphs to determine the reachability with higher confidence. Finally, we iterate all of the appropriate nodes and check their reachability status according to the information collected in 2 previous paths.
With these 2 this rule went from `-24%` to `~-2%`.
This performance gain doesn't come for free though; It increases the likelihood of false positives/negatives, But as long as we are passing our `ecosystem-ci` it should be fine. We can always sacrifice some performance to check for edge cases if there are any.
[new oxlint-echosystem-ci result](https://github.com/rzvxa/oxlint-ecosystem-ci/actions/runs/9490791181)
This PR aims to provide a more accurate error/finalization flow, I've nuked the old error path approach and rewrote it with more versatility in mind.
We used to visit the finalizer block twice and create 2 sets of AstNodes/Basic Blocks for them, This was there to differentiate between the error path finalizer and success path one. There is no longer a need for having 2 separate sets of nodes to do this differentiation.
As for the error path now we have 2 kinds of them, Everything is attached to an error block - even if it is not in a try-catch statement - this results in a lot of extra edges to keep track of these "Implicit" error blocks but I believe in future it can help us to track cross block error paths, For example, we can dynamically attach and cache the implicit error block of a function to its call site error path (either implicit or explicit).
Correct the `#[visited_node]` attr on `ArrowFunctionExpression` to recognise strict mode functions.
This change has no effect at present as `Traverse` codegen currently ignores `strict_if`. But useful for it to be correct for if we codegen `Visit` / `VisitMut` later on (#3392).
Replace recursion with loop in
`JSXMemberExpression::get_object_identifier`.
Also add a mutable version
`JSXMemberExpression::get_object_identifier_mut`.
Re-use existing `Atom`s in React Display Name transform rather than writing duplicate strings into the arena.
Also add comments for where our implementation diverges from Babel's (in my opinion, ours is an improvement).
`AstBuilder` only contains a shared ref `&Allocator`. So make it `Copy` and pass around `AstBuilder<'a>` instead of `&AstBuilder<'a>` - 1 less level of indirection.
Hopefully this will have little effect on benchmarks as all `AstBuilder`'s methods are marked `#[inline]`, but this change will minimize impact if compiler decides not to inline for some reason.
Update scope attrs used by `oxc_traverse` codegen on `MethodDefinition` and `Function` types. These attrs are currently ignored by the codegen anyway, so causes no change in generated code, but bringing them up to date in preparation for #3392.
