The JSON superset proposal is at stage 3. It's stable enough that I think we should just let it ride the train to release.

Per https://github.com/tc39/proposal-json-superset#implementations this is going to ship in Chrome/Safari. We should probably implement this.

test262 tests have also landed, but we currently can't easily update test262, because BigInt tests were added to existing test files for Atomics, which means when updated we won't be able to run the Atomics tests anymore. IOW the update is blocked by <https://github.com/tc39/test262/pull/1533>.

I can take this. I would prefer to work it in around various bits of single-byte tokenizing I'm working on, tho. It would be super-convenient for all line breaks to be a single code unit in UCS-2 and UTF-8 both, but I'd rather not intertwine the two efforts' fates such that if the proposal weren't adopted, we couldn't easily readd support.

The proposal was updated to Stage 4, which means it is now part of ES2019. It is already implemented in Chrome 66 and Safari TP49, maybe this issue needs some "parity" flags.

I passed the GIT-INFO rev on the command line for this.

Comment on attachment 8980801 [details] [diff] [review] Allow U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR, encoding those literal code points, inside string literals Review of attachment 8980801 [details] [diff] [review]: ----------------------------------------------------------------- r+ with comments addressed and EvalStringMightBeJSON [1] updated to match the new behaviour. [1] https://searchfox.org/mozilla-central/rev/ce86c6c0472d5021ef693cf99abaaa0644c89e55/js/src/builtin/Eval.cpp#138 ::: js/src/frontend/TokenStream.cpp @@ +2417,2 @@ > if (!parsingTemplate) { > + // String literals don't allow ASCIIs line breaks. s/ASCIIs/ASCII/ presumably? ::: js/src/jit-test/tests/latin1/json.js @@ -60,5 @@ > - throw new Error("U+2028 shouldn't eval"); > - } catch (e) { > - assertEq(e instanceof SyntaxError, true, > - "should have thrown a SyntaxError, instead got " + e); > - } Please keep this test (after changing the expected value), because it tests the eval-JSON optimization. ::: js/src/tests/non262/eval/line-terminator-paragraph-terminator.js @@ -22,5 @@ > -} > - > -try > -{ > - var r = eval('"\u2028"'); This one can go away, because it's a duplicate of what's in test262. @@ -33,5 @@ > -} > - > -try > -{ > - var r = eval('("\u2028")'); Probably also want to keep this one, because of the eval-JSON interactions. @@ -44,5 @@ > -} > - > -try > -{ > - var r = eval('"\u2029"'); This one can go away, because it's a duplicate of what's in test262. @@ -55,5 @@ > -} > - > -try > -{ > - var r = eval('("\u2029")'); Probably also want to keep this one, because of the eval-JSON interactions.

Pushed by jwalden@mit.edu: https://hg.mozilla.org/integration/mozilla-inbound/rev/637c5fc9bcb4 Allow U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR, encoding those literal code points, inside string literals. r=anba https://hg.mozilla.org/integration/mozilla-inbound/rev/18381864eb87 Reimport test262 tests with the json-superset tests not disabled. r=anba

Backout by toros@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/2948af44622f Backed out 3 changesets (bug 1435828, bug 1464472) for build bustages and reftest failures on a CLOSED TREE

Backed out 3 changesets (bug 1435828, bug 1464472) for build bustages and reftest failures Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/2948af44622f481f704636556e43da92ff6bde99 Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=ad6e1c06f4d76667e00ae0b520eff0225292396a Failure log file: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&fromchange=7381b7b49ef2e48f829ad233854cb46999d8282e&selectedJob=180624607

Pushed by jwalden@mit.edu: https://hg.mozilla.org/integration/mozilla-inbound/rev/1a85fc556cd3 Allow U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR, encoding those literal code points, inside string literals. r=anba https://hg.mozilla.org/integration/mozilla-inbound/rev/cc3808652819 Reimport test262 tests with the json-superset tests not disabled. r=anba

Just a typo in the first part here, relanded with the typo fixed.

https://hg.mozilla.org/mozilla-central/rev/1a85fc556cd3 https://hg.mozilla.org/mozilla-central/rev/cc3808652819

Announced on Firefox 62 for developers: https://developer.mozilla.org/en-US/Firefox/Releases/62#JavaScript Reference page updates: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON#JavaScript_and_JSON_differences https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#String_literals Compat data update: https://github.com/mdn/browser-compat-data/pull/2409 There is also this widely cited article: http://timelessrepo.com/json-isnt-a-javascript-subset Maybe the author will update it https://github.com/judofyr/timeless/issues/74 Waldo, can you double-check if the MDN doc updates make sense to you? Thanks!

"extend ECMA-262 syntax into a superset of JSON" is a somewhat obscure way to describe the *effect* of this change. I would instead suggest: * JavaScript string literals may now directly contain U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR. As a consequence, JSON syntax is now a subset of JavaScript literal syntax. As for https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON#JavaScript_and_JSON_differences "some JavaScript is not JSON, and some JSON is not JavaScript" is now wrong -- I'd fix it by removing ",...not JavaScript". And instead of a full separate section for "...is now a..." (a title that inherently grows more and more inaccurate), I would replace the heading and section with """ Any JSON text is a valid JavaScript expression -- but only in JavaScript engines that have implemented the [proposal to make all JSON text valid ECMA-262](https://github.com/tc39/proposal-json-superset). In engines that haven't implemented the proposal, U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR are allowed in string literals and property keys in JSON; but their use in these features in JavaScript literals is a syntax error. var code = '"\u2028\u2029"'; JSON.parse(code); // evaluates to "\u2028\u2029" in all engines eval(code); // throws a SyntaxError in old engines """

Thanks for your review! :) I've updated the pages based on your suggestions.