The following testcase shows different behavior with options --ion -n -m --ion-eager vs. --no-ion on ionmonkey revision beabf74b228d: function toPrinted(value) { if (typeof value == "xml") value = value.toXMLString(); } function reportCompare (expected, actual, description) { var output = ""; output += "Expected value '" + toPrinted(expected) + "', Actual value '" + toPrinted(actual) + "' "; } options("allow_xml"); function f(x) { return let ([] = 0xffffffff ^ x) XMLList(); } reportCompare ("PASSED", f(true), "Unqualified reference should not see Function.prototype"); $ debug64/js --ion -n -m --ion-eager test.js test.js:3: TypeError: is not a function $ debug64/js --no-ion test.js <no output or error> This is the same problem as in bug 758384, but that bug is marked fixed.

Given the plan to deprecate E4X, I'm tempted to WONTFIX this unless you think it will cause problems for the fuzzer. This correctness bug is very, very specific to calling E4X functions and is unlikely to hit unless --ion-eager is specified.

(In reply to David Anderson [:dvander] from comment #1) > Given the plan to deprecate E4X, I'm tempted to WONTFIX this unless you > think it will cause problems for the fuzzer. This correctness bug is very, > very specific to calling E4X functions and is unlikely to hit unless > --ion-eager is specified. The fact that --ion-eager is required doesn't help since we need that to reproduce most of the bugs. If we can delete some object in the fuzzer so we don't hit this anymore, then we can WONTFIX it from my side. Otherwise, it'll cause lots instances in the fuzzer that we have to manually investigate (and for differential testing, there is no duplicate detection).

Can you exclude testcases that contain "allow_xml" from differential testing?

(In reply to Jesse Ruderman from comment #3) > Can you exclude testcases that contain "allow_xml" from differential testing? No, since allow_xml is not introduced by the fuzzer but rather by the top level shell.js (at least it was at that time when this test came up). Maybe this can be rearranged. My driver overloads options() and disallows any options changing but it's loaded after the toplevel shell.

Assuming this really only was a problem with E4X.