637204 - Some unconditionally reserved words are reserved only in strict code

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Mark S. Miller]

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?

Comment 1

[Brendan Eich [:brendan]]

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

Comment 2

[Jeff Walden [:Waldo]]

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.

Comment 3

[Brendan Eich [:brendan]]

Has anyone filed a bug on V8?

/be

Comment 4

[Mark S. Miller]

http://code.google.com/p/v8/issues/detail?id=1214

Comment 5

[Mark S. Miller]

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

Comment 6

[Jeff Walden [:Waldo]]

Attachment: Patch, reenable the test

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.

Comment 7

[Jeff Walden [:Waldo]]

Attachment: Oops, missed some changes

Comment 8

[Brendan Eich [:brendan]]

(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

Comment 9

[Jeff Walden [:Waldo]]

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.

Comment 10

[Jeff Walden [:Waldo]]

Attachment: diff -w without function name bits

Comment 11

[Jeff Walden [:Waldo]]

Filed bug 638667 for the function-name change.

Comment 12

[Brendan Eich [:brendan]]

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

Comment 13

[Jeff Walden [:Waldo]]

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

Comment 14

[Jeff Walden [:Waldo]]

http://hg.mozilla.org/tracemonkey/rev/9abe76d26196

Comment 15

[Chris Leary [:cdleary] (not checking bugmail)]

http://hg.mozilla.org/mozilla-central/rev/9abe76d26196

Comment 16

[Jorge Villalobos [:jorgev] (he/him)]

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

Comment 17

[Tyler Breisacher]

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

Comment 18

[Eric Shepherd [:sheppy]]

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

Comment 19

[Jeff Walden [:Waldo]]

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

Comment 20

[Eric Shepherd [:sheppy]]

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.