The following testcase crashes on mozilla-central revision 20210317-9ad67cd4d216 (debug build, run with --fuzzing-safe --no-threads --scalar-replace-arguments --ion-warmup-threshold=0 --baseline-warmup-threshold=0):

'use strict'
function bar(x,y) {}
function foo(x, y) {
    function closeOver() {
      return x;
    }
    return bar.apply({}, arguments);
}
var sum = 0;
for (var i = 0; i < 100; i++)
    sum += foo(1,2);

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x00005555575edd8e in js::jit::ArgumentsReplacer::visitGuardArgumentsObjectFlags(js::jit::MGuardArgumentsObjectFlags*) ()
#1  0x00005555575ec581 in js::jit::ArgumentsReplacer::run() ()
#2  0x00005555575ee5de in js::jit::ScalarReplacement(js::jit::MIRGenerator*, js::jit::MIRGraph&) ()
#3  0x000055555788229d in js::jit::OptimizeMIR(js::jit::MIRGenerator*) ()
#4  0x000055555788af4c in js::jit::CompileBackEnd(js::jit::MIRGenerator*, js::jit::WarpSnapshot*) ()
#5  0x000055555788c82e in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned char*) ()
#6  0x000055555788d3a7 in IonCompileScriptForBaseline(JSContext*, js::jit::BaselineFrame*, unsigned char*) ()
#7  0x00001c76cb289715 in ?? ()
[...]
#16 0x0000000000000000 in ?? ()
rax	0x55555586eb9f	93824995486623
rbx	0x7ffff60e9078	140737321537656
rcx	0x555557ff33b8	93825036923832
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7fffffffb3f0	140737488335856
rsp	0x7fffffffb3e0	140737488335840
r8	0x7ffff7105770	140737338431344
r9	0x7ffff7f99840	140737353717824
r10	0x58	88
r11	0x7ffff6dac7a0	140737334921120
r12	0x7ffff60e90c0	140737321537728
r13	0x7ffff60e75d0	140737321530832
r14	0x0	0
r15	0x7ffff60e7560	140737321530720
rip	0x5555575edd8e <js::jit::ArgumentsReplacer::visitGuardArgumentsObjectFlags(js::jit::MGuardArgumentsObjectFlags*)+318>
=> 0x5555575edd8e <_ZN2js3jit17ArgumentsReplacer30visitGuardArgumentsObjectFlagsEPNS0_26MGuardArgumentsObjectFlagsE+318>:	movl   $0x5e6,0x0
   0x5555575edd99 <_ZN2js3jit17ArgumentsReplacer30visitGuardArgumentsObjectFlagsEPNS0_26MGuardArgumentsObjectFlagsE+329>:	callq  0x555556a7ec64 <abort>

Bugmon Analysis:
Verified bug as reproducible on mozilla-central 20210320085643-f56d2bf535d6.
The bug appears to have been introduced in the following build range:

Start: cfffb092a39f8a76a485e8e2399d91c24a1c9810 (20210212202418)
End: 776c08d542f8f27bbbdb7594e8baf4c0bdbc3b19 (20210212203140)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cfffb092a39f8a76a485e8e2399d91c24a1c9810&tochange=776c08d542f8f27bbbdb7594e8baf4c0bdbc3b19

When we are guarding that no argument is forwarded, ArgumentsReplacer::visitGuardArgumentsObjectFlags asserts that no formal argument is aliased. This is too general: in strict mode, arguments can be aliased by the call object, but not forwarded.

This patch fixes the check in anyFormalIsAliased and renames it for clarity.

(I tried adding assertions in MaybeForwardToCallObject that we only mark arguments as forwarded if script->anyFormalIsAliased(), but that runs into problems with arguments.callee.arguments and ArgumentsObject::createUnexpected.)

https://hg.mozilla.org/mozilla-central/rev/fe9b5592cd31

Bugmon Analysis:
Verified bug as fixed on rev mozilla-central 20210324040732-768e04aaea52.
Removing bugmon keyword as no further action possible.
Please review the bug and re-add the keyword for further analysis.