Closed
Bug 626596
Opened 14 years ago
Closed 13 years ago
JM: Different enumeration order (interpreter vs JM) after calling a function on a string literal
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: gkw, Assigned: dvander)
References
Details
(Keywords: regression, testcase)
try { n("".v()) } catch(e) {} try { function l() {} function decodeURIComponent() {} print(uneval(this)) } catch(e) {} Tested on TM changeset 4046ef71ddc2 stdout without -m: ({l:function l() {}, decodeURIComponent:function decodeURIComponent() {}}) stdout with -m: ({decodeURIComponent:function decodeURIComponent() {}, l:function l() {}}) === autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 57677:47729824b12c user: Brendan Eich date: Tue Oct 26 19:12:40 2010 -0700 summary: Property enumeration order is altered after a method has been read (601399, r=jorendorff).
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 1•14 years ago
|
||
Seems like it could be important for web compat.
blocking2.0: ? → betaN+
Whiteboard: hardblocker
Assignee | ||
Updated•14 years ago
|
Assignee: general → dvander
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•14 years ago
|
||
This observable difference in enumeration order is because normally the string class wouldn't lazily resolve until decodeURIComponent() is resolved. However, a callprop on a string literal will lazily resolve String from inside the method JIT compiler. Since this only happens when calling methods on string literals, and the only observable effect is enumeration order on the global object, I don't think this should block.
blocking2.0: betaN+ → -
Comment 3•14 years ago
|
||
I call toLowerCase/toUpperCase on string literals fairly often. But I usually don't rely on enumeration order :)
Summary: JM: Different output (interpreter vs JM) with given testcase involving decodeURIComponent, uneval → JM: Different enumeration order (interpreter vs JM) after calling a function on a string literal
Comment 4•14 years ago
|
||
This is so not a blocker. We should fix standard class init to be eager and super-fast, memcpy plus pointer fixups. I filed a bug on that but can't spot it atm. Can someone cite it? /be
Reporter | ||
Updated•14 years ago
|
Severity: critical → normal
Reporter | ||
Updated•14 years ago
|
Whiteboard: hardblocker
Reporter | ||
Comment 5•13 years ago
|
||
try { w("".l) } catch (e) {} try { function l() {} function decodeURIComponent() {} for (let y in this) { print(y); } } catch (e) {} A variant testcase causes the following difference in output, in JM with TI: $ ./js-opt-64-jm-darwin -m -a -n testcase.js decodeURIComponent l $ ./js-opt-64-jm-darwin testcase.js l decodeURIComponent
Comment 6•13 years ago
|
||
Current js shell results for comment #0 testcase: Interp: ({l:function l() {}, decodeURIComponent:function decodeURIComponent() {}}) JM: ({l:function l() {}, decodeURIComponent:function decodeURIComponent() {}}) JM+TI: ({l:function l() {}, decodeURIComponent:function decodeURIComponent() {}}) Current js shell results for comment #5 testcase: Interp: l decodeURIComponent JM: l decodeURIComponent JM+TI: l decodeURIComponent
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Updated•13 years ago
|
Flags: in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•