Bugzilla

This actually has nothing to do with Warp/Ion. It's a difference between the C++ interpreter and the jits. Specifically, the CacheIR implementation of `tryAttachAddOrUpdateSparseElement` is incorrect: it doesn't check to see if the prototype is frozen. The first time we try to assign to `v21[0]`, we attach an IC that doesn't enforce the shadowing behaviour, then call into the VM for the actual operation. The second time, we use the IC and incorrectly set the value.

The following testcase has differential behaviour with/without `--blinterp-eager`: 
```
const arr = [];

Array.prototype[0] = 123;
Object.freeze(Array.prototype);

for (var i = 0; i < 2; i++) {
  arr[0] = 321;
}
print(arr[0]);
```

At first glance, I think we should probably be reusing [some of the checks](https://searchfox.org/mozilla-central/rev/9ca193b4233957439583f2eadabbd3cfb4cd9fed/js/src/jit/CacheIR.cpp#4118-4121,4125-4128) from `tryAttachSetDenseElementHole` in `tryAttachAddOrUpdateSparseElement`.

This actually has very little to do with Warp/Ion. It's a difference between the C++ interpreter and the jits. Specifically, the CacheIR implementation of `tryAttachAddOrUpdateSparseElement` is incorrect: it doesn't check to see if the prototype is frozen. The first time we try to assign to `v21[0]`, we attach an IC that doesn't enforce the shadowing behaviour, then call into the VM for the actual operation. The second time, we use the IC and incorrectly set the value.

The following testcase has differential behaviour with/without `--blinterp-eager`: 
```
const arr = [];

Array.prototype[0] = 123;
Object.freeze(Array.prototype);

for (var i = 0; i < 2; i++) {
  arr[0] = 321;
}
print(arr[0]);
```

At first glance, I think we should probably be reusing [some of the checks](https://searchfox.org/mozilla-central/rev/9ca193b4233957439583f2eadabbd3cfb4cd9fed/js/src/jit/CacheIR.cpp#4118-4121,4125-4128) from `tryAttachSetDenseElementHole` in `tryAttachAddOrUpdateSparseElement`.

This actually has very little to do with Warp/Ion. It's a difference between the C++ interpreter and the jits. Specifically, the CacheIR implementation of `tryAttachAddOrUpdateSparseElement` is incorrect: it doesn't check to see if the prototype is frozen. The first time we try to assign to `v21[0]`, we attach an IC that doesn't enforce the shadowing behaviour, then call into the VM for the actual operation. The second time, we use the IC and incorrectly set the value.

The following testcase has differential behaviour with/without `--blinterp-eager`: 
```
const arr = [];

Array.prototype[0] = 123;
Object.freeze(Array.prototype);

for (var i = 0; i < 2; i++) {
  arr[0] = 321;
}
print(arr[0]);
```

At first glance, I think we should probably be reusing [some of the checks](https://searchfox.org/mozilla-central/rev/9ca193b4233957439583f2eadabbd3cfb4cd9fed/js/src/jit/CacheIR.cpp#4118-4121) from `tryAttachSetDenseElementHole` in `tryAttachAddOrUpdateSparseElement`.