Till Schneidereit [:till] Reporter
	Description • 6 years ago

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.

	Tom S [:evilpie]
	Comment 1 • 6 years ago

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

	André Bargull [:anba]
	Comment 2 • 6 years ago

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>.

	Jeff Walden [:Waldo] Assignee
	Comment 3 • 6 years ago

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.

	Alexandre Folle de Menezes
	Comment 4 • 6 years ago

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.

	Jeff Walden [:Waldo] Assignee
	Comment 6 • 6 years ago

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

	André Bargull [:anba]
	Comment 7 • 6 years ago

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.

	Pulsebot
	Comment 8 • 6 years ago

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

	Pulsebot
	Comment 9 • 6 years ago

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

	Tiberius Oros[:tiberius_oros]
	Comment 10 • 6 years ago

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

	Pulsebot
	Comment 11 • 6 years ago

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

	Jeff Walden [:Waldo] Assignee
	Comment 12 • 6 years ago

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

	Noemi Erli[:noemi_erli]
	Comment 13 • 6 years ago
bugherder

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

	Florian Scholz (Open Web Docs)
	Comment 14 • 6 years ago

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!

	Jeff Walden [:Waldo] Assignee
	Comment 15 • 6 years ago

"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
"""

	Florian Scholz (Open Web Docs)
	Comment 16 • 6 years ago

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