The following test asserts on mozilla-central revision 4de07a341aab (options -m -n -a): .__proto__();
If I had to guess, I'm betting this has to do with the JSOP_QNAMEPART fugliness for property accesses for __proto__. h8
This has not been fixed on m-c changeset 7c7d2a8db7ff (which has bug 716713 included) autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 84036:7ab4f1ebc7cc user: Brian Hackett date: Mon Jan 09 06:29:50 2012 -0800 summary: Backout 54cd89b0f1fa (bug 712714 backout). Talos will probably report fake regressions for this patch, do not back out for this reason.
Created attachment 587907 [details] [diff] [review] rm fugliness Yeah, it's the __proto__ special casing. This bug removes that stuff entirely. It seems only necessary so that the interpreter does not have to check for __proto__ when doing GetProtoIfDenseArray. Interpreter optimizations are no longer necessary/justifiable, and while PICs should still be able to do this stuff they can test for __proto__ before generating code.
(In reply to Brian Hackett (:bhackett) from comment #3) > Interpreter optimizations are no longer necessary/justifiable Overstated this a bit. Having significant complexity to occasionally save a few cycles while interpreting is not good.
Comment on attachment 587907 [details] [diff] [review] rm fugliness Review of attachment 587907 [details] [diff] [review]: ----------------------------------------------------------------- And there was much rejoicing.
Backed out for not building on any platforms except the ones I tested on. https://hg.mozilla.org/integration/mozilla-inbound/rev/408ab9247ef1
Created attachment 598057 [details] [diff] [review] weaken assert Unfortunately the QNAMEPART stuff is also necessary for correct behavior of __proto__ on primitives (which should get e.g. Number.prototype instead of Object.prototype) and there doesn't seem to be an easy/efficient way to fix this. So here's a patch which weakens the assert so that the goofy SWAP; SWAP sequence of bytecodes emitted here is passed through.
Automatically extracted testcase for this bug was committed: https://hg.mozilla.org/mozilla-central/rev/efaf8960a929