The "prototype" property of function instances is not enumerable in ES5; it was in ES3. See URL for some es-discuss talk about this, although it appears the change mostly flew under the radar without active discussion. Browsers disagree on this a bit, and given the late date ES5 will most likely go with what it currently has, so we should change accordingly. I discovered this while writing tests for bug 505587.

Comment on attachment 398624 [details] [diff] [review] Patch Here's hoping this doesn't break anything of note on the web. /be

http://hg.mozilla.org/tracemonkey/rev/991d79f172c3 This reminds me, we should probably remove prototype as a property from non-user-defined functions (Object/Number/etc.) while we're mucking here, better all at once than a change here, a change there, maybe-breaking every time -- will search for that bug and hack out a fix now.

This will intentionally break a handful of tests in the test suite. Given that this will introduce a divergence between latest and past-version tests and their expected results, I'm not sure what to do about the tests yet -- pinging bc to see what the proper thing to do is.

(In reply to comment #3) > http://hg.mozilla.org/tracemonkey/rev/991d79f172c3 > > This reminds me, we should probably remove prototype as a property from > non-user-defined functions (Object/Number/etc.) Uh, those have standard prototype properties and [[Construct]] internal methods per spec. You must mean eval, parseInt, etc... > while we're mucking here, > better all at once than a change here, a change there, maybe-breaking every > time -- will search for that bug and hack out a fix now. ...which would be bug 202019. /be

But 202019 is low priority. The v8 engine has the same kind of bug where they self-hosted built-ins, and they haven't fixed it yet. /be

(In reply to comment #5) > Uh, those have standard prototype properties and [[Construct]] internal methods > per spec. > > You must mean eval, parseInt, etc... Yeah, I forgot a "not" in there. Others not having fixed it isn't really a reason to not fix it yet, but I'm reasonably convinced the two cases are qualitatively different. Also, the easy fix for removing prototype -- defining the prototype only if FUN_INTERPRETED -- doesn't quite work because Function.prototype is, oddly enough, interpreted, and making sure not to give that a prototype property is probably important to a fully correct fix.

(In reply to comment #4) > This will intentionally break a handful of tests in the test suite. Given that > this will introduce a divergence between latest and past-version tests and > their expected results, I'm not sure what to do about the tests yet -- pinging > bc to see what the proper thing to do is. We are no longer tied to keeping the tests identical across repos/branches. Fix the tests to work on the branch where the patch lands and land those changes with your patch. If the patch makes it to other repos/branches the test changes will/should/must travel with them.

are these the expected failures from this patch? If so, please update the tests. ecma/extensions/15.1.2.1-1.js | var PROPS = ''; for ( p in eval ) { PROPS += p }; PROPS wrong value item 3 ecma/GlobalObject/15.1.2.2-1.js | var PROPS=''; for ( var p in parseInt ) { PROPS += p; }; PROPS wrong value item 3 ecma/GlobalObject/15.1.2.3-1.js | var MYPROPS=''; for ( var p in parseFloat ) { MYPROPS += p }; MYPROPS wrong value item 5 ecma/GlobalObject/15.1.2.4.js | var MYPROPS=''; for ( var p in escape ) { MYPROPS+= p}; MYPROPS wrong value item 5 ecma/GlobalObject/15.1.2.5-1.js | var MYPROPS=''; for ( var p in unescape ) { MYPROPS+= p }; MYPROPS wrong value item 5 ecma/GlobalObject/15.1.2.6.js | var MYPROPS=''; for ( var p in isNaN ) { MYPROPS+= p }; MYPROPS wrong value item 2 ecma/GlobalObject/15.1.2.7.js | var MYPROPS=''; for ( p in isFinite ) { MYPROPS+= p }; MYPROPS wrong value item 5 js1_5/extensions/regress-383965.js | getter function with toSource Expected match to '/({get aaa :{}})|({aaa:{prototype:{}}})/', Actual value '({aaa:{}})' item 1 js1_5/Function/10.1.6-01.js | Local variables should not be enumerable properties of the function Expected value 'prototype,', Actual value '' item 1

(In reply to comment #9) > are these the expected failures from this patch? If so, please update the > tests. Yes, done. http://hg.mozilla.org/tracemonkey/rev/4ea50daa0a18

Jeff, you missed js1_5/Function/10.1.6-01.js

(In reply to comment #11) > Jeff, you missed js1_5/Function/10.1.6-01.js Oops, http://hg.mozilla.org/tracemonkey/rev/9ea1e7be6331

Whiteboarding this as applying to Gecko 1.9.3; let me know if this is expected to land on Firefox 3.6.

sayrer: http://hg.mozilla.org/tracemonkey/rev/4ea50daa0a18 and http://hg.mozilla.org/tracemonkey/rev/9ea1e7be6331 need to land on 1.9.2 as well.