Some unconditionally reserved words are reserved only in strict code

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
trivial
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Mark S. Miller, Assigned: Waldo)

Tracking

({dev-doc-complete, relnote})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

6 years ago
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
(Reporter)

Comment 4

6 years ago
http://code.google.com/p/v8/issues/detail?id=1214
(Reporter)

Comment 5

6 years ago
See also https://bugs.webkit.org/show_bug.cgi?id=55342
Created attachment 516127 [details] [diff] [review]
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.
Assignee: general → jwalden+bmo
Status: NEW → ASSIGNED
Attachment #516127 - Flags: review?(brendan)
Created attachment 516384 [details] [diff] [review]
Oops, missed some changes
Attachment #516127 - Attachment is obsolete: true
Attachment #516127 - Flags: review?(brendan)
Attachment #516384 - Flags: review?(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
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.
Created attachment 516780 [details] [diff] [review]
diff -w without function name bits
Attachment #516384 - Attachment is obsolete: true
Attachment #516384 - Flags: review?(brendan)
Attachment #516780 - Flags: review?(brendan)
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
Attachment #516780 - Flags: review?(brendan) → review+
Yeah, looks like it's test262 (and based on the test names, Sputnik before it) wins here.  Will blog, too, after I land this.
http://hg.mozilla.org/tracemonkey/rev/9abe76d26196
Whiteboard: fixed-in-tracemonkey
http://hg.mozilla.org/mozilla-central/rev/9abe76d26196
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
This should be mentioned in the Firefox 5 compatibility docs since it can and will break a number of add-ons.
Keywords: dev-doc-needed

Updated

6 years ago
Keywords: relnote

Comment 17

6 years ago
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.
Keywords: dev-doc-needed → dev-doc-complete
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.
You need to log in before you can comment on or make changes to this bug.