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`
The typescript transform pass is now required to strip typescript syntax
for codegen to print things properly.
Codegen will now print whatever is in the AST.
closes#3663 this time for real😅
browser search doesn't work in the GitHub actions (because of the partial rendering I guess) I had to use GitHub's own log search to see all instances related to this rule.
[oxlint-ecosystem-ci](https://github.com/rzvxa/oxlint-ecosystem-ci/actions/runs/9512820948)
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).
close: #3620
In `Babel`, the expected output is:
```ts
var x = 10;
var Foo = function(Foo) {
Foo[Foo['a'] = 10] = 'a';
Foo[Foo['b'] = 10] = 'b';
Foo[Foo['c'] = 30] = 'c';
return Foo;
}(Foo || {});
```
IMO, `Foo.b + x` is enough, because `x` is not a const variable. The
output same as with `typescript`
I've just created example using `oxc_semantic`.
> https://gist.github.com/leaysgur/bcb748daa665d1615eabda6967366d05
But it could not be compiled due to:
```
error: to use a constant of type `CtxFlags` in a pattern, `CtxFlags` must be annotated with `#[derive(PartialEq, Eq)]`
```
- 0.14.0: 🆖
- ...
- 0.13.0: 🆖
- 0.12.5: 🆗
This change seems to fix this.
