Implement JSON superset proposal

RESOLVED FIXED in Firefox 62

Status

()

P3
normal
RESOLVED FIXED
a year ago
9 months ago

People

(Reporter: till, Assigned: Waldo)

Tracking

(Blocks: 1 bug, {dev-doc-complete})

Trunk
mozilla62
dev-doc-complete
Points:
---

Firefox Tracking Flags

(firefox60 wontfix, firefox61 wontfix, firefox62 fixed)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

a year 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.
Priority: -- → P3
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>.
(Assignee)

Comment 3

10 months 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.
Assignee: nobody → jwalden+bmo
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.
(Assignee)

Comment 6

10 months ago
I passed the GIT-INFO rev on the command line for this.
Attachment #8980802 - Flags: review?(andrebargull)
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.
Attachment #8980801 - Flags: review?(andrebargull) → review+

Updated

10 months ago
Attachment #8980802 - Flags: review?(andrebargull) → review+

Comment 8

10 months 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

Comment 9

10 months 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

Comment 11

10 months 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
(Assignee)

Comment 12

10 months ago
Just a typo in the first part here, relanded with the typo fixed.
Flags: needinfo?(jwalden+bmo)
Blocks: 1435795
No longer blocks: 1435811

Comment 13

10 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/1a85fc556cd3
https://hg.mozilla.org/mozilla-central/rev/cc3808652819
Status: NEW → RESOLVED
Last Resolved: 10 months ago
status-firefox62: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
status-firefox60: affected → wontfix
status-firefox61: --- → wontfix
(Assignee)

Comment 15

9 months 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
"""
Flags: needinfo?(jwalden+bmo)
Thanks for your review! :) I've updated the pages based on your suggestions.
You need to log in before you can comment on or make changes to this bug.