Avoid truncating inferred arity to 8 bits

Parameter counts are recorded via len() as u8, which silently wraps for functions with more than 255 parameters; those wrapped values are later used by ignore_unused_args_of_call to delete trailing arguments. In such cases, real positional arguments can be removed incorrectly (e.g. 300 params inferred as 44), producing wrong runtime inputs. Please store arity in a wider type or mark it unknown when it exceeds u8::MAX.

Useful? React with 👍 / 👎.

mark_param_count uses Value<u8>, which will force call sites to truncate params.len() for functions with >255 parameters. That can lead to incorrect param_count and unsafe argument dropping. Consider using a larger integer type here (e.g. u16/usize) or specifying that overflow must map to Value::Unknown and enforcing it at the API boundary.

Propagate param_count when merging child-scope data

This new param_count field is never merged in ProgramData::merge, so bindings keep a stale known arity when a nested block/function assigns a different callee. For example, let f = a => a; if (cond) { f = (a, b) => b } f(1, 2) records the reassignment in the child scope, but the parent VarUsageInfo still looks like arity 1, so ignore_unused_args_of_call can delete the second argument even when the branch executes.

Useful? React with 👍 / 👎.

Require definite function initialization before trimming identifier calls

This treats any recorded param_count as proof that the callee is already a function at this call site, but the analyzer records arity from later initializers and assignments too. That makes calls like function g(){ f(0, sideEffect()); var f = a => a } unsafe: at runtime f is still undefined, so sideEffect() runs before the TypeError, while this path can drop the second argument entirely. Please gate this on the binding being definitely initialized to that function before the call, rather than only on a known arity.

Useful? React with 👍 / 👎.

Invalidate stored arity on update expressions

This also trusts param_count after writes like f++, but the new arity tracking is only cleared from visit_assign_expr; visit_update_expr still just reports an assignment and leaves the old count intact. In let f = a => a; f++; f(0, sideEffect()), f becomes NaN, the original program evaluates sideEffect() before throwing, and this optimization can incorrectly remove that trailing argument because the stale arity is still recorded as 1.

Useful? React with 👍 / 👎.

Invalidate cached arity on for…in/of loop rebindings

This path trusts param_count even after the callee variable has been rebound by a loop head. In crates/swc_ecma_usage_analyzer/src/analyzer/mod.rs, visit_for_in_stmt / visit_for_of_stmt assign through report_assign_pat (lines 167-172, 919-960), but that helper never calls mark_param_count(Value::Unknown), and ForHead::VarDecl heads also skip any arity invalidation. A case like let f = a => a; for (f in {x:1}) break; f(0, sideEffect()) therefore keeps the old arity of f, so this optimization can drop sideEffect() even though the runtime call now throws only after evaluating it.

Useful? React with 👍 / 👎.

param_count is stored as Value<u8>, but the analyzer writes params.len() as u8. If a function has >255 parameters, this will truncate and can make ignore_unused_args_of_call drop arguments incorrectly. Consider using a wider integer type (e.g. u16/usize) or at minimum treat params.len() > u8::MAX as Unknown when recording the count.

ignore_unused_args_of_call mutates/removes call arguments but never sets self.changed = true (and doesn’t emit a report_change!) when it actually drops/replaces args. This can prevent follow-up optimizations in later passes that depend on the changed flag. Please mark the optimizer as changed whenever an argument is removed or rewritten here.

For Expr::Ident callees, the safety check only looks at self.ctx.scope for eval/with, but the callee binding may come from an outer scope that contains eval/with (which can dynamically rebind the function and invalidate the recorded param_count). This can make argument-dropping unsound for captured variables. Consider also bailing out when the program/top scope has HAS_EVAL_CALL/HAS_WITH_STMT, or using VarUsageInfoFlags (e.g. USED_IN_NON_CHILD_FN) to conservatively avoid using param_count across scope boundaries when eval/with exists.

Honor enclosing eval/with scopes before trimming identifier calls

This guard only inspects self.ctx.scope, but visit_mut_block_stmt switches ctx.scope to each nested block and ScopeData::merge only propagates HAS_EVAL_CALL/HAS_WITH_STMT upward. As a result, f(1, 2) inside an inner block can still be rewritten to f(1) even when an enclosing function or with statement has already made f dynamically rebindable, e.g. function outer(){ let f = a => a; eval("f = (_, b) => b"); { return f(1, 2); } }. Please walk enclosing scopes (or use the existing BitCtx::InWithStmt) before trusting param_count here.

Useful? React with 👍 / 👎.

Restrict arity trimming to declared local callees

This branch trusts any stored param_count for identifier callees, but param_count is also populated for unresolved assignments in visit_assign_expr (e.g. f = (a)=>a). In non-strict/script code those are global-property bindings, so a later write like globalThis.f = (_, b) => b can change the runtime callee without invalidating this cached arity; rewriting f(1, sideEffect()) to f(1) then drops observable argument evaluation. Please require a definitely declared local binding (or otherwise exclude unresolved/global bindings) before using param_count here.

Useful? React with 👍 / 👎.

Invalidate arity for wrapped assignment targets

When the left-hand side is wrapped (e.g. (f as any) = ..., f! = ..., or parenthesized forms), n.left.as_ident() is None, so this falls back to find_pat_ids(&n.left). find_pat_ids intentionally ignores expressions, so no identifier is found and param_count is not invalidated. That leaves stale known arity for f, and ignore_unused_args_of_call can later drop side-effectful trailing arguments from f(...) after such reassignments.

Useful? React with 👍 / 👎.

Preserve potentially throwing trailing arguments

This new call-arity trimming path removes an argument whenever ignore_return_value returns None, but that helper can drop expressions that are side-effect-free yet still throw when evaluated (for example, 1n + 1). In a case like function f(a){}; f(0, 1n + 1), this optimization now rewrites to f(0) and suppresses the runtime TypeError, which is a behavior change. The trailing argument should only be removed when evaluation is guaranteed not to throw.

Useful? React with 👍 / 👎.

Treat one-sided child arity merges as unknown

ProgramData::merge preserves a known param_count when only one side has data ((Known, None) or (None, Known)), but this merge runs for child scopes that may not execute (e.g. if branches and nested function bodies). That makes arity look definite when it is path-dependent: in let f; if (cond) { f = a => a } f(0, sideEffect()), the branch contributes Known(1) and this arm keeps it, so ignore_unused_args_of_call can drop sideEffect() even though cond = false leaves f non-callable and the original program still evaluates that argument before throwing.

Useful? React with 👍 / 👎.