for each (let b in [(-1/0), new String(''), new String(''), null, (-1/0), (-1/0), new String(''), new String(''), null]) '' + b;
This is due to classifying null as object when tracing and in typemaps. We need to null-guard, which is another branch test for a rare hard case. I think it is better to classify null as a distinct type. undefined arguably should be its own trace typemap type too, but at least it's lumped into boolean. Imagine if it were included in object -- that's analogous to what we do with null. /be
Assignee: general → brendan
Status: NEW → ASSIGNED
OS: Mac OS X → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.9.1
Would it make sense to group null and undefined together as one tracing type?
Summary: Crash [@ JITted code] with this type-unstable loop → TM: Crash [@ JITted code] with this type-unstable loop
No longer crashes. Instead, incorrectly throws "TypeError: b is null" (only with JIT on).
WFM now that bug 465460 is fixed. /be
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Adding fixed1.9.1 as bug 465460 is fixed1.9.1
Whiteboard: [fixed by 465460]
js1_8/regress/regress-465454.js v 1.9.1, 1.9.2
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in before you can comment on or make changes to this bug.