The current implementations does not work. Under linux it tells me 0
files, under windows:
```
> oxc-vscode@0.15.5 lint C:\dev\oxc\editors\vscode
> npx oxlint --config=oxlint.json --tsconfig=tsconfig.json client/*.js
Finished in 5ms on 5 files with 101 rules using 24 threads.
Found 0 warnings and 0 errors.
```
I do not think this glob is needed. we are using `ignore` in our
`Walker`, which should already covering the use case.
---------
Co-authored-by: Sysix <alexander.schlegel@clicksports.de>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Some types' properties have names that require `r#` escape, and we can't really avoid it. But in my view, it's preferable not to name vars `r#...` when we don't have to.
Bump MSRV to 1.79 in line with our policy to support last 6 minor versions.
We can now use `const {}` expressions which became stable in 1.79. https://releases.rs/docs/1.79.0/
Implement `IntoIterator` for `&mut Vec` like `std::vec::Vec` does. This allows shorter and more idiomatic syntax.
Before:
```rs
for item in object.collection.iter_mut() {
// ...
}
```
After:
```rs
for item in &mut object.collection {
// ...
}
```
Lifetime on our impl of `IntoIterator` for `&Vec` was wrong.
Previously:
```rs
impl<'alloc, T> IntoIterator for &'alloc Vec<'alloc, T> {
type IntoIter = std::slice::Iter<'alloc, T>;
type Item = &'alloc T;
fn into_iter(self) -> Self::IntoIter { self.0.iter() }
}
```
This means that the iterator borrows the `Vec` for the lifetime of the allocator, which is way too long. It should only borrow it for the lifetime of the reference `&Vec`. Insisting we borrow the `Vec` for so long to iterate over it was unnecessarily restrictive.
Instead:
```rs
impl<'i, T> IntoIterator for &'i Vec<'_, T> {
type IntoIter = std::slice::Iter<'i, T>;
type Item = &'i T;
fn into_iter(self) -> Self::IntoIter { self.0.iter() }
}
```
This matches the lifetimes on [`allocator_api2::vec::Vec`'s implementation](63cd7fcc2f/src/stable/vec/mod.rs (L2682-L2690)).
This `super.value` belongs to the nested class, we shouldn't transform it.
```js
class Outer {
async method() {
class Inner extends Outer {
normal() {
// `super.value` should not be transformed, because it is not in an async method
super.value
}
}
}
}
```
No stronger opinion on both implementations, I just think the scope-based is clearer, and iterating over scope is always faster than node. The only bad point in this implementation we don't have specific ScopeFlags for class methods, thus we need to check if the parent of the function is a `MethodDefinition`
Missing error that super property inside plain function.
```js
class C {
constructor() {
function g() {
// * It is a Syntax Error if PropName of MethodDefinition is not "constructor" and HasDirectSuper of MethodDefinition is true.
super();
}
}
method() {
function func() {
// It is a Syntax Error if FunctionBody Contains SuperProperty is true.
super.good();
}
}
}
```
I am not sure why test262 doesn't cover tests like that
The simplified version of the evaluation of `a = a || b` is:
> AssignmentExpression : LeftHandSideExpression = LogicalORExpression || LogicalANDExpression
> 1. Let lRef be ? Evaluation of LeftHandSideExpression.
> 2. Let llRef be ? Evaluation of LogicalORExpression.
> 3. Let llVal be ? GetValue(llRef).
> 4. If ToBoolean(llVal) is true
> a. Perform ? PutValue(lRef, llVal).
> b. return llVal.
> 5. Let lrRef be ? Evaluation of LogicalANDExpression.
> 6. Let rRef be ? GetValue(lrRef).
> 7. Let rVal be ? GetValue(rRef). [Note GetValue(rRef) returns rRef itself]
> 8. Perform ? PutValue(lRef, rVal).
> 9. Return rVal.
The simplified version of the evaluation of `a ||= b` is:
> AssignmentExpression : LeftHandSideExpression ||= AssignmentExpression
> 1. Let lRef be ? Evaluation of LeftHandSideExpression.
> 2. Let lVal be ? GetValue(lRef).
> 3. If ToBoolean(lVal) is true, return lVal.
> 4. Let rRef be ? Evaluation of AssignmentExpression.
> 5. Let rVal be ? GetValue(rRef).
> 6. Perform ? PutValue(lRef, rVal).
> 7. Return rVal.
The difference of these is that
- the evaluation of `a` is done twice for `a = a || b`, one with `1. Let lRef be ? Evaluation of LeftHandSideExpression` and one with `2. Let llRef be ? Evaluation of LogicalORExpression.`. This is same with #8366, #8367.
- `PutValue(lRef, llVal)` is performed when `ToBoolean(lVal)` is `true`.
So `x = x || 1` can be compressed to `x ||= 1` when the conditions written in #8366 are met and `PutValue(lRef, llVal)` does not have a side effect. When `a` is a non-global identifier (and not a reference created by a `with` statement), these conditions are met.
**References**
- [Spec of `||`](https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-binary-logical-operators-runtime-semantics-evaluation)
- [Spec of `=` / `||=`](https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-binary-logical-operators-runtime-semantics-evaluation)
The simplified version of the evaluation of `a += b` is:
> AssignmentExpression : LeftHandSideExpression AssignmentOperator AssignmentExpression
> 1. Let lRef be ? Evaluation of LeftHandSideExpression.
> 2. Let lVal be ? GetValue(lRef).
> 3. Let rRef be ? Evaluation of AssignmentExpression.
> 4. Let rVal be ? GetValue(rRef).
> 5. Let r be ? ApplyStringOrNumericBinaryOperator(lVal, opText, rVal).
> 6. Perform ? PutValue(lRef, r).
> 7. Return r.
The simplified version of the evaluation of `a = a + b` is:
> AssignmentExpression : LeftHandSideExpression = AssignmentExpressionLeft + AssignmentExpressionRight
> 1. Let lRef be ? Evaluation of LeftHandSideExpression.
> 2. Let alRef be ? Evaluation of AssignmentExpressionLeft.
> 3. Let alVal be ? GetValue(alRef).
> 4. Let arRef be ? Evaluation of AssignmentExpressionRight.
> 5. Let arVal be ? GetValue(arRef).
> 6. Let rRef be ? ApplyStringOrNumericBinaryOperator(alVal, opText, arVal).
> 7. Let rVal be ? GetValue(rRef). [Note GetValue(rRef) returns rRef itself]
> 8. Perform ? PutValue(lRef, rVal).
> 9. Return rVal.
The difference of these is that the evaluation of `a` is done twice for `a = a + b`, one with `1. Let lRef be ? Evaluation of LeftHandSideExpression` and one with `2. Let alRef be ? Evaluation of AssignmentExpressionLeft.`
So this is same with #8366 and can be compressed similarly when the conditions are met (`a.b = a.b + c` -> `a.b += c`).
**References**
- [Spec of `=`, `+=`](https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-assignment-operators-runtime-semantics-evaluation)
- [Spec of `+`](https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-addition-operator-plus-runtime-semantics-evaluation)
Fix panic if a private accessor is present in class which also has property. e.g.:
```js
let C = class C {
prop = 1;
accessor #private = 2;
};
```
Panic occurred due to trying to unwrap `brand` property, but it's `None` because no private instance methods in the class.
No temp var is required for class if it contains static private method which is not referenced within class. e.g.:
```js
let C = class {
static #method() {}
};
```
->
```js
let C = class {};
function _method() {}
```
Small improvement. Use `Class::type` field to determine if class is declaration/expression. Not sure why it did it in such a complicated way previously!
In the following case, async methods can be nested in another async method. The implementation is changing to store `super_methods` on a stack, and then we can store super method information in the correct `super_methods` map.
```js
const outer = {
value: 0,
async method() {
() => super.value;
const inner = {
value: 0,
async method() {
() => super.value;
}
};
() => super.value;
}
};
```
