Some unconditionally reserved words are reserved only in strict code: class, enum, export, extends, import, super I am submitting this classified as "trivial" because these are properly rejected in strict code, which is all I really care about. If someone does care about this case, please raise the severity. If this is closed as a wont-fix, could we also have a tag like DeliberateSpecViolation (as v8 now has) so we can more easily keep track of such cases?

See bug 497869. We can try to reserve harder next time (or the time after that, with a quarterly release schedule) -- it will take more testing and possibly even cross-browser coordination. /be

Chrome and Opera are the only other engines that make these not keywords. IE never unreserved them, and I think WebKit didn't either (or at least in my testing back when they were reserved outside strict mode). I think this mostly just needs some lag time for Mozilla-centric sites (like the ones mentioned in that bug) that seemingly didn't care about cross-browser behavior to get fixed.

Has anyone filed a bug on V8? /be

See also https://bugs.webkit.org/show_bug.cgi?id=55342

Interestingly it seems the current code had a bug with just the token-type change. I didn't notice it when we initially changed this because I'd written a not-complete test at the time. But since then I landed bug 629187, which beefed up the test quite a bit, adding the new tests that fail without the jsparse.cpp changes in here. Hurray for more-complete tests finding failures! It'd be good to land this early this next cycle so anyone using these names as keywords can adapt, therefore doing this now rather than any later. If we can land when TM/m-c reopen to post-4.0 work that gets us the maximum nightly coverage possible, which can only be a good thing.

(In reply to comment #6) > Interestingly it seems the current code had a bug with just the token-type > change Do you mean the parser enabling keyword-as-name for function names (identifiers after 'function' keywords and the 'function::' namespace)? That was intentional: revision 3.227 date: 2006/09/07 11:28:30; author: igor.bukanov%gmail.com; state: Exp; lines: +17 -3 Bug 343675: allow to use keywords as function names. r=brendan (CVS log entry.) Undoing this extension is a separate proposal from fixing this bug, unless I am missing something here that requires removing the extension. We don't have to sort this out here. New bug? I will review a focused patch quickly. /be

Yeah, that was it. I'll see what I can do. I think, with some effort, I can special-case those bits in the test that was detecting this instance of not allowing keywords in this one place. Back in a bit with that change, I hope.

Filed bug 638667 for the function-name change.

Comment on attachment 516780 [details] [diff] [review] diff -w without function name bits Does this buy us spec conformance wins with sputnik or test262? It's not good for much more, but we may as well get it in and start breaking all the scofflaw JS content out there. /be

Yeah, looks like it's test262 (and based on the test names, Sputnik before it) wins here. Will blog, too, after I land this.

This should be mentioned in the Firefox 5 compatibility docs since it can and will break a number of add-ons.

https://developer.mozilla.org/en/JavaScript/Reference/Reserved_Words should be updated as well.

Hm... was this in Firefox 5? For some reason, it's flagged in our doc spreadsheet as being for Firefox 7.

Pretty sure this was 5 and changed not at all in 7.

OK, this had been documented already for Firefox 5, but was for some reason on our list for Firefox 7. I've checked the docs, and things are good.