do-while grammar
FWIW, JavaScriptCore provides automatic semicolon insertion after all do-while statements in all contexts. We made this change for web compatibility, mimicking a Firefox quirk.
Geoff
Just for the record, here's a link to the bug report on bugzilla concerning ASI for do-while: bugzilla.mozilla.org/show_bug.cgi?id=238945
(Interesting that I came across the very same issue in January while working on the OpenLaszlo parser code :-)
Thanks for the info guys!
My best,
Dave
From: André Bargull [mailto:andre.bargull at udo.edu] Sent: Tuesday, February 08, 2011 12:12 PM To: ggaren at apple.com Cc: Dave Fugate; es-discuss Subject: Re: do-while grammar
Just for the record, here's a link to the bug report on bugzilla concerning ASI for do-while: bugzilla.mozilla.org/show_bug.cgi?id=238945
(Interesting that I came across the very same issue in January while working on the OpenLaszlo parser code :-)
FWIW, JavaScriptCore provides automatic semicolon insertion after all do-while statements in all contexts. We made this change for web compatibility, mimicking a Firefox quirk.
Geoff
On Feb 8, 2011, at 11:53 AM, Dave Fugate wrote:
Just to confirm, do-while iteration statements do in fact require a semi-colon at the end as indicated in 12.6.1 of ES5, correct? That is, a production of the nature: do {;} while (false) false;
would be invalid JavaScript as doesn't meet any of the three rules set out in 7.9.1, right?
Thanks,
Does anyone know of any other syntax that all major JS engines accept that are not in the official ES5.1 grammar?
Does anyone know of any places on the web attempting to accumulate such exceptions?
The other one I know of is nested named function declarations < conventions:no_non_standard_strict_decls>.
And there was an ASI mis-description for "break" and "continue" that was corrected between ES5 and ES5.1.
We really need a complete codification of the consensus ES5.1 grammar. Starting from the official grammar, the Caja < caja.appspot.com/trycaja/index.html?input=do {%3B} while(false) false>
and ES-Lab es-lab.googlecode.com/svn/trunk/site/esparser/index.html
parsers both reject "do {;} while (false) false;" because we didn't know any better. I expect there are many other independent parsers (minimizers, linters, etc) that make the same mistake.
Even if such "corrections" do not make it into future errata, I would like to see them recorded on the ecmascript wiki.
The do-while one slipped my mind, sorry. I obviously knew about it in 2004, when we changed SpiderMonkey in pre-Firefox-1, also Narcissus.
One was of cross-checking is to look at Narcissus. We've been building it up to have a Harmony mode, adding ES5 support before that (still some missing), and running it on our test-suites. But I wrote Narcissus in 2004 based on ES3 plus only enough reality to self-host. So looking at how it differs from ES3, in all versions from 2004 up to today, could be helpful.
I just reviewed the Narcissus parser, and this do-while case is the only ASI variance noted. The other supported extensions to ES3 (get and set in object initialisers, catch guards) are disabled by an option: --ecma3-only).
see below On Feb 8, 2011, at 2:01 PM, Mark S. Miller wrote:
Does anyone know of any other syntax that all major JS engines accept that are not in the official ES5.1 grammar?
Yes, various RegExp syntax discrepancies are know to exist. Somebody needs to catalog them.
Does anyone know of any places on the web attempting to accumulate such exceptions?
None that I know of that I would unconditionally trust.
The other one I know of is nested named function declarations conventions:no_non_standard_strict_decls. And there was an ASI mis-description for "break" and "continue" that was corrected between ES5 and ES5.1.
There really isn't any useful common semantics for function declaration in blocks. See blogs.msdn.com/b/ie/archive/2010/08/25/chakra-interoperability-means-more-than-just-standards.aspx
We really need a complete codification of the consensus ES5.1 grammar. Starting from the official grammar, the Caja caja.appspot.com/trycaja/index.html?input=do {%3B} while(false) false and ES-Lab es-lab.googlecode.com/svn/trunk/site/esparser/index.html parsers both reject "do {;} while (false) false;" because we didn't know any better. I expect there are many other independent parsers (minimizers, linters, etc) that make the same mistake.
Even if such "corrections" do not make it into future errata, I would like to see them recorded on the ecmascript wiki.
I was going to suggest that the place to start is bugs.ecmascript.org, but you beat me to it.
On Tue, Feb 8, 2011 at 5:01 PM, Mark S. Miller <erights at google.com> wrote:
Does anyone know of any other syntax that all major JS engines accept that are not in the official ES5.1 grammar?
Does anyone know of any places on the web attempting to accumulate such exceptions?
I've been meaning to start a place like that, but haven't had a chance yet.
There's wiki.whatwg.org/wiki/Web_ECMAScript
Lasse recently posted about regex deviations here — www.mail-archive.com/[email protected]/msg05328.html S. Levithan should probably know more cases.
Someone who worked on ES parser recently, like Benjamin Rosseaux (author of BESEN) or Peter van der Zee (ES parser at esparser.qfox.nl) might be able to throw in more cases (cc'ing them).
That couple-years-old MS document about JScript deviations might have more.
[...]
On Feb 8, 2011, at 2:41 PM, Allen Wirfs-Brock wrote:
The other one I know of is nested named function declarations conventions:no_non_standard_strict_decls. And there was an ASI mis-description for "break" and "continue" that was corrected between ES5 and ES5.1.
There really isn't any useful common semantics for function declaration in blocks. See blogs.msdn.com/b/ie/archive/2010/08/25/chakra-interoperability-means-more-than-just-standards.aspx
Yet we keep running into bugs where someone uses function-in-block intersection semantics.
Clearly it's useful, since we want it in Harmony. Of course, it's not supported so developers counting on it are on thin ice regarding name collisions, name leaks, etc.
Most recent example:
bugzilla.mozilla.org/show_bug.cgi?id=630851
See bugzilla.mozilla.org/show_bug.cgi?id=630851#c8 in particular.
Nevertheless, we are banning function-in-block under Firefox 4's ES5 strict mode implementation.
Right, no "useful common semantics" doesn't means that there aren't specific (perhaps many) cases that will work in all current browsers. It just means that it is hard to find a generalization of those specific cases that could be a useful implementable semantics that would be worth trying to spec. One might be: the enclosing function only contains a single declaration for inner function F and all references to F must be in the same block as the declaration of F and follow the declaration.
On 2/8/2011 11:41 PM, Allen Wirfs-Brock wrote:
see below On Feb 8, 2011, at 2:01 PM, Mark S. Miller wrote:
Does anyone know of any other syntax that all major JS engines accept that are not in the official ES5.1 grammar?
Yes, various RegExp syntax discrepancies are know to exist. Somebody needs to catalog them.
Especially the discrepancies which are visible when executing the few RegExp examples from the ES3/ES5 specification are quite amusing.
"A<B>bold</B>and<CODE>coded</CODE>".split(new RegExp("<(/)?([^<>]+)>")) => Wrong result in Firefox/IE
"ab".split(new RegExp("a*")) => Wrong result in IE
new RegExp("((a)|(ab))((c)|(bc))").exec("abc") => Wrong result in IE
new RegExp("(z)((a+)?(b+)?(c))*").exec("zaacbbbcac") => Wrong result in Safari/IE
new RegExp("(.?)a(?!(a+)b\2c)\2(.)").exec("baaabaac") => Wrong result in Safari/IE
(Tested with current IE, Firefox, Safari, Opera)
On Feb 8, 2011, at 3:35 PM, André Bargull wrote:
On 2/8/2011 11:41 PM, Allen Wirfs-Brock wrote:
see below On Feb 8, 2011, at 2:01 PM, Mark S. Miller wrote:
Does anyone know of any other syntax that all major JS engines accept that are not in the official ES5.1 grammar?
Yes, various RegExp syntax discrepancies are know to exist. Somebody needs to catalog them.
Especially the discrepancies which are visible when executing the few RegExp examples from the ES3/ES5 specification are quite amusing.
"A<B>bold</B>and<CODE>coded</CODE>".split(new RegExp("<(/)?([^<>]+)>")) => Wrong result in Firefox/IE
Firefox 4 beta-recent agrees with Safari and Chrome, FYI.
On Feb 8, 2011, at 3:35 PM, André Bargull wrote:
new RegExp("(z)((a+)?(b+)?(c))*").exec("zaacbbbcac") => Wrong result in Safari/IE
new RegExp("(.*?)a(?!(a+)b\2c) => Wrong result in Safari/IE
FYI these should be fixed in Safari with a WebKit nightly build.
Fwiw I don't recall any specific cases of input accepted by browsers which shouldn't parse according to the spec, other than functions in statements. Even "callable regular expressions" are fine as far as the grammar goes. I don't have an extensive test suite for regular expressions or strict mode though. Not yet, anyways.
The do-while case should indeed not have ASI applied unless allowed by 7.9.1 (so the given test case should fail). I think this is assumed, but it wasn't explicitly stated in the thread.
On Feb 9, 2011, at 12:35 AM, Peter van der Zee wrote:
Fwiw I don't recall any specific cases of input accepted by browsers which shouldn't parse according to the spec, other than functions in statements. Even "callable regular expressions" are fine as far as the grammar goes. I don't have an extensive test suite for regular expressions or strict mode though. Not yet, anyways.
WebKit nightlies don't allow callable RegExps anymore -- I haven't yet heard of any fallout from this change.
better late than never:)
It's a bit hard to digest, but I'm slowly accumulating this info in the form of disabled Test262 testshg.ecmascript.org/tests/test262/file/3d8a9eee876d/test/config/excludelist.xml and bugs. Wouldn't take too much effort to turn this into something a bit more readable on the Wiki. Aside from the bugs already filed and what's been mentioned in this thread, there's a couple more I can think of offhand:
-
"\X12" (versus "\x12") -
"\U0001" (versus "\u0001")
My best,
Dave
From: Mark S. Miller [mailto:erights at google.com] Sent: Tuesday, February 08, 2011 2:01 PM To: andre.bargull at udo.edu Cc: ggaren at apple.com; Dave Fugate; es-discuss Subject: Re: do-while grammar
Does anyone know of any other syntax that all major JS engines accept that are not in the official ES5.1 grammar?
Does anyone know of any places on the web attempting to accumulate such exceptions?
The other one I know of is nested named function declarations conventions:no_non_standard_strict_decls. And there was an ASI mis-description for "break" and "continue" that was corrected between ES5 and ES5.1.
We really need a complete codification of the consensus ES5.1 grammar. Starting from the official grammar, the Caja <caja.appspot.com/trycaja/index.html?input=do {%3B} while(false) falsecaja.appspot.com/trycaja/index.html?input=do {%3B} while(false) false> and ES-Lab es-lab.googlecode.com/svn/trunk/site/esparser/index.html parsers both reject "do {;} while (false) false;" because we didn't know any better. I expect there are many other independent parsers (minimizers, linters, etc) that make the same mistake.
Even if such "corrections" do not make it into future errata, I would like to see them recorded on the ecmascript wiki.
On Tue, Feb 8, 2011 at 12:12 PM, André Bargull <andre.bargull at udo.edu<mailto:andre.bargull at udo.edu>> wrote:
Just for the record, here's a link to the bug report on bugzilla concerning ASI for do-while: bugzilla.mozilla.org/show_bug.cgi?id=238945
(Interesting that I came across the very same issue in January while working on the OpenLaszlo parser code :-)
FWIW, JavaScriptCore provides automatic semicolon insertion after all do-while statements in all contexts. We made this change for web compatibility, mimicking a Firefox quirk.
Geoff
On Feb 8, 2011, at 11:53 AM, Dave Fugate wrote:
Just to confirm, do-while iteration statements do in fact require a semi-colon at the end as indicated in 12.6.1 of ES5, correct? That is, a production of the nature: do {;} while (false) false;
would be invalid JavaScript as doesn't meet any of the three rules set out in 7.9.1, right?
Thanks,
Just to confirm, do-while iteration statements do in fact require a semi-colon at the end as indicated in 12.6.1 of ES5, correct? That is, a production of the nature: do {;} while (false) false;
would be invalid JavaScript as doesn't meet any of the three rules set out in 7.9.1, right?
Thanks,
Just to confirm, do-while iteration statements do in fact require a semi-colon at the end as indicated in 12.6.1 of ES5, correct? That is, a production of the nature: do {;} while (false) false; would be invalid JavaScript as doesn't meet any of the three rules set out in 7.9.1, right? Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110208/6dca0b85/attachment.html>