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.
VSCode has a couple violations. examples:
```
x oxc(no-accumulating-spread): Do not spread accumulators in loops
,-[src/vs/workbench/services/textMate/common/TMGrammarFactory.ts:65:5]
64 | let injections: string[] = [];
65 | for (let i = 1; i <= scopeParts.length; i++) {
: ^|^
: `-- For this loop
66 | const subScopeName = scopeParts.slice(0, i).join('.');
67 | injections = [...injections, ...(this._injections[subScopeName] || [])];
: ^^^^^^|^^^^^^
: `-- From this spread
68 | }
`----
help: Consider using `Object.assign()` or `Array.prototype.push()` to mutate the accumulator instead.
Using spreads within accumulators leads to `O(n^2)` time complexity.
x oxc(no-accumulating-spread): Do not spread accumulators in loops
,-[src/vs/base/common/actions.ts:205:3]
204 | let out: IAction[] = [];
205 | for (const list of actionLists) {
: ^|^
: `-- For this loop
206 | if (!list.length) {
207 | // skip
208 | } else if (out.length) {
209 | out = [...out, new Separator(), ...list];
: ^^^|^^
: `-- From this spread
210 | } else {
`----
help: Consider using `Object.assign()` or `Array.prototype.push()` to mutate the accumulator instead.
Using spreads within accumulators leads to `O(n^2)` time complexity.
help: It looks like you're spreading an `Array`. Consider using the `Array.push` or `Array.concat` methods to mutate the accumulator instead.
Using spreads within accumulators leads to `O(n^2)` time complexity.
x oxc(no-accumulating-spread): Do not spread accumulators in loops
,-[src/vs/workbench/contrib/extensions/browser/extensionsActions.ts:302:3]
301 | let actions: IAction[] = [];
302 | for (const visibleActions of actionsGroups) {
: ^|^
: `-- For this loop
303 | if (visibleActions.length) {
304 | actions = [...actions, ...visibleActions, new Separator()];
: ^^^^^|^^^^
: `-- From this spread
305 | }
`----
help: Consider using `Object.assign()` or `Array.prototype.push()` to mutate the accumulator instead.
Using spreads within accumulators leads to `O(n^2)` time complexity.
x oxc(no-accumulating-spread): Do not spread accumulators in loops
,-[src/vs/workbench/contrib/extensions/browser/extensionsActions.ts:1141:3]
1140 | let actions: IAction[] = [];
1141 | for (const menuActions of menuActionGroups) {
: ^|^
: `-- For this loop
1142 | actions = [...actions, ...menuActions, new Separator()];
: ^^^^^|^^^^
: `-- From this spread
1143 | }
`----
help: Consider using `Object.assign()` or `Array.prototype.push()` to mutate the accumulator instead.
Using spreads within accumulators leads to `O(n^2)` time complexity.
x oxc(no-accumulating-spread): Do not spread accumulators in loops
,-[src/vs/workbench/contrib/extensions/browser/extensionsViews.ts:334:4]
333 | let actions: IAction[] = [];
334 | for (const menuActions of groups) {
: ^|^
: `-- For this loop
335 | actions = [...actions, ...menuActions, new Separator()];
: ^^^^^|^^^^
: `-- From this spread
336 | }
`----
help: Consider using `Object.assign()` or `Array.prototype.push()` to mutate the accumulator instead.
Using spreads within accumulators leads to `O(n^2)` time complexity.
```
`TraverseCtx::ancestors` iterator would previously yield `Some(Ancestor::None)` before finally yielding `None`. Skip `Ancestor::None` as it's pointless.
Change meaning of `level` passed to `TraverseCtx` from "levels above current" to "levels above parent". `ctx.parent()`'s equivalent was `ctx.ancestor(1)`, now it's `ctx.ancestor(0)`.
This prevents out of bounds read on `ctx.ancestor(0)` (UB), which was made possible by #5286.
Preparation for upstack PRs. Graphical reporter diagnostics look exactly the same. This does, however, change `to_string()` to only show diagnostic messages, and not error codes + messages.
