when reporting diagnotics for code such as
```ts
let foo = {};
for (let i = 0; i < 10; i++) {
foo = { ...foo, [i]: i };
}
```
we do not currently differentiate the diagnostic message between object/array.
this PR changes this to help the user fix ths issue
when reporting diagnotics for code such as
```ts
let foo = {};
for (let i = 0; i < 10; i++) {
foo = { ...foo, [i]: i };
}
```
we do not currently report **where** the accumulator is defined.
since this is constant for `Array.prototype.reduce`, it is not necessary.
however for loops, it makes sense to add this span to clearly show the user where the accumator is defined.
fixes#5159 and any other named function assigned to a property like:
```js
const foo = {};
foo.bar = function fooBar() {}
```
---------
Co-authored-by: Don Isaac <donald.isaac@gmail.com>
Co-authored-by: Cameron Clark <cameron.clark@hey.com>
Adds `no-async-endpoint-handlers` rules, which bans async functions used as endpoint handlers in Express applications. These do not get caught by Express' error handler, causing the server to crash with an unhandled process rejection error.
```js
app.use(async (req, res) => {
const foo = await api.getFoo(req.query) // server panics if this function rejects
return res.json(foo)
})
```
I could not find this rule implemented in any ESLint plugin, but this is a problem I see quite often and I'm tired of dealing with it. I've added it to `oxc` for now, but we should consider adding an `express` or `api` plugin in the future.
`AstBuilder::move_assignment_target` pass a static `Atom` instead of empty string to `AstBuilder::simple_assignment_target_identifier_reference`. This avoids a call to `alloc` to allocate an empty string in arena.
follow-up: https://github.com/oxc-project/oxc/pull/4587#issue-2440174935
The `CalculateSignatureKey`is used to collect signature keys, but since it requires a double visit, it doesn't perform very well. Now I use ScopeId to store the signature key that is generated in `CallExpression`. This way we can then determine which ArrowFunction/Function the `CallExpression` belongs to.
Follow-on after #5223. We're trying to ignore JSX identifiers, so there's no point walking downwards from `JSXElementName`, as all we'll find is JSX identifiers that we want to ignore.
Follow-on after #5223.
Now that we are getting an `IdentifierReference` with a `reference_id`, we can use that ID for a faster lookup of whether the reference is bound or not.
Outside of the parser, a `JSXIdentifier` in a `JSXElementName::Identifier` will never be a identifier reference. So move the code for deciding if a `JSXElementName` is `JSXElementName::Identifier` or `JSXElementName::IdentifierReference`, and the code for converting from one to the other, into the parser - which is only place it should be used.
#5223 added a new variant `JSXElementName::IdentifierReference` for JSX identifiers which are treated as references (e.g. `<Foo>`) as opposed to `JSXElementName::Identifier` which is for lowercase (e.g. `<div>`).
But we were incorrectly categorizing identifiers beginning with `_` or `$` - these should also be treated as references.
(as discussed in https://github.com/oxc-project/oxc/pull/5339#issuecomment-2321037779)
Follow-on after #5223.
#5223 introduced the line `let span = jsx_el.opening_element.name.span();`. But the span is only needed when creating a diagnostic when the rule fails (cold path). Avoid the work of getting the span for the common case where the rule passes.
Follow-on after #5223.
JSX identifiers which start with a capital letter are now `JSXElementName::IdentifierReference`s, so no need to check for capitalized `JSXElementName::Identifier`s.
Box `TSThisParameter` in `Function`, `TSMethodSignature` and `TSFunctionType`. I assume `function(this: Whatever) {}` is a fairly rare syntax in TS code, and obviously never occurs in JS code, so it takes up a lot of space in `Function` for this uncommon case.
This change reduces `Function` from 136 bytes to 104.
