Normative: Make B.1.{1,2} normative #1867

jmdyck · 2020-02-09T02:20:19Z

This PR comprises the first 2 commits of PR #1651, which I gather are "non-controversial".

bakkot · 2020-02-10T00:05:33Z

Note that this will require a change to test262 (to remove tests for the non-annex B behavior and move the annex B tests to the main directory).

jmdyck · 2020-02-24T02:26:52Z

(force-pushed to resolve merge conflicts and fix some mistakes)

littledan · 2020-02-24T10:22:34Z

cc @waldemarhorwat

erights · 2020-02-24T19:30:16Z

Where can I find this text rendered into an html page?

(I think someone told me before but I can't find it.)

evilpie · 2020-02-24T19:37:06Z

https://arai-a.github.io/ecma262-compare/#pr=1867

bakkot · 2020-02-24T19:39:27Z

Where can I find this text rendered into an html page?

If you click "show all checks" at the bottom of any PR, the "Details" link next to the netlify one gives you the rendered HTML.

erights · 2020-02-24T21:34:21Z

Thanks!

erights

LGTM. Thanks!

jmdyck · 2020-04-25T18:59:34Z

(force-pushed to resolve merge conflicts)

michaelficarra · 2020-10-08T00:13:31Z

This normative change is marked as neither has consensus nor needs consensus. What gives?

bakkot · 2020-10-08T01:02:36Z

@michaelficarra In #1595 we got consensus for moving parts of annex B into the main spec, but there is apparently not agreement about exactly which parts, leaving us in a slightly awkward state.

erights · 2020-10-08T01:28:29Z

@michaelficarra In #1595 we got consensus for moving parts of annex B into the main spec, but there is apparently not agreement about exactly which parts, leaving us in a slightly awkward state.

Which parts do you think remain unresolved?

michaelficarra · 2020-10-08T01:30:56Z

@erights Are you implying that the changes in this PR all have consensus?

erights · 2020-10-08T01:44:00Z

Not necessarily. But I remember that we did once have consensus. From @bakkot 's comment, it sounded like there are particular things that we don't remember what we agreed on, or if we agreed. What are they? I might remember.

ljharb · 2020-10-08T05:54:33Z

@erights as i recall, we got consensus to move all syntax/parsing items into the main spec (but i don't recall if those were to be marked normative optional, or left required) - but all the other items were to be evaluated case-by-case.

jmdyck · 2020-10-17T02:29:49Z

force-pushed to resolve merge conflicts and handle NonOctalDecimalEscapeSequence added in PR #2054.

jmdyck · 2021-06-10T19:24:49Z

Can you open an issue so we can track it and address it with a normative PR once we have consensus to do so?

Done.

ljharb · 2021-07-11T04:00:39Z

spec.html

+        <ul>
+          <li>It is a Syntax Error if the source code matching this production is strict mode code.</li>
+        </ul>
+        <emu-note>In non-strict code, this syntax is legacy.</emu-note>


Suggested change

<emu-note>In non-strict code, this syntax is legacy.</emu-note>

<emu-note>In non-strict code, this syntax is Legacy.</emu-note>

since i think we want it to auto-link to the dfn added in #2125?

ljharb · 2021-07-11T04:01:01Z

spec.html

+        <ul>
+          <li>It is a Syntax Error if the source code matching this production is strict mode code.</li>
+        </ul>
+        <emu-note>In non-strict code, this syntax is legacy.</emu-note>


Suggested change

<emu-note>In non-strict code, this syntax is legacy.</emu-note>

<emu-note>In non-strict code, this syntax is Legacy.</emu-note>

jmdyck · 2021-07-24T01:28:03Z

force-pushed to:

rebase to master, resolving conflicts from PR 2469;
add squashable commits to change "legacy" to "Legacy"

bakkot · 2021-07-28T22:20:08Z

spec.html

@@ -27035,10 +27178,10 @@ <h1>Forbidden Extensions</h1>
        The Syntactic Grammar must not be extended in any manner that allows the token `:` to immediately follow source text that matches the |BindingIdentifier| nonterminal symbol.
      </li>
      <li>
-        When processing strict mode code, the syntax of |NumericLiteral| must not be extended to include <emu-xref href="#prod-annexB-LegacyOctalIntegerLiteral"></emu-xref> and the syntax of |DecimalIntegerLiteral| must not be extended to include <emu-xref href="#prod-annexB-NonOctalDecimalIntegerLiteral"></emu-xref> as described in <emu-xref href="#sec-additional-syntax-numeric-literals"></emu-xref>.
+        When processing strict mode code, an implementation must not relax the early error rules of <emu-xref href="#sec-numeric-literals-early-errors"></emu-xref>.


It's odd that we list the restriction for numeric literals and templates but not strings, here, but I guess that was the status quo as well.

(see issue #2432)

jmdyck · 2021-07-29T01:30:14Z

Since this seems to be close to merging, note to @ljharb that I'd like to handle squashing it down.

bakkot · 2021-08-11T21:55:58Z

@jmdyck I think this is ready, if you want to do the squashing now.

(Part of Annex B reform, see PR tc39#1595.)

... and replace the former with the latter in TemplateCharacter. The spec prohibits applying the B.1.2 extensions to EscapeSequence when it appears in TemplateCharacter; this change accomplishes that in the grammar rather than in prose. (This makes it a little easier to 'mainline' the B.1.2 extensions in the next commit.)

(Part of Annex B reform, see PR tc39#1595.) B.1.2 makes 2 changes to the EscapeSequence production: (1) It adds the rhs `NonOctalDecimalEscapeSequence`. (2) It replaces the rhs: `0` [lookahead <! DecimalDigit] with: LegacyOctalEscapeSequence where the latter nonterminal generates `0` among lots of other things. Change 1 is straightforward, but change 2 is tricky. In the EscapeSequence production, we can't simply replace the `0` alternative with LegacyOctalEscapeSequence (as B.1.2 does), because the `0` alternative must be treated differently from everything else that LegacyOctalEscapeSequence derives. (The `0` alternative is allowed in contexts where everything else that LegacyOctalEscapeSequence derives is forbidden.) So instead, we redefine LegacyOctalEscapeSequence to exclude the `0` alternative. Specifically, the 'overlap' comes from: LegacyOctalEscapeSequence :: OctalDigit [lookahead ∉ OctalDigit] so we replace that with: LegacyOctalEscapeSequence :: `0` [lookahead ∈ {`8`, `9`}] NonZeroOctalDigit [lookahead ∉ OctalDigit] (See Issue tc39#1975 for more details.) Resolves tc39#1975.

jmdyck · 2021-08-12T20:20:29Z

force-pushed to:

rebase to master
squash it down to 3 commits
polish the commit messages

(Part of Annex B reform, see PR tc39#1595.)

... and replace the former with the latter in TemplateCharacter. The spec prohibits applying the B.1.2 extensions to EscapeSequence when it appears in TemplateCharacter; this change accomplishes that in the grammar rather than in prose. (This makes it a little easier to 'mainline' the B.1.2 extensions in the next commit.)

(Part of Annex B reform, see PR tc39#1595.) B.1.2 makes 2 changes to the EscapeSequence production: (1) It adds the rhs `NonOctalDecimalEscapeSequence`. (2) It replaces the rhs: `0` [lookahead <! DecimalDigit] with: LegacyOctalEscapeSequence where the latter nonterminal generates `0` among lots of other things. Change 1 is straightforward, but change 2 is tricky. In the EscapeSequence production, we can't simply replace the `0` alternative with LegacyOctalEscapeSequence (as B.1.2 does), because the `0` alternative must be treated differently from everything else that LegacyOctalEscapeSequence derives. (The `0` alternative is allowed in contexts where everything else that LegacyOctalEscapeSequence derives is forbidden.) So instead, we redefine LegacyOctalEscapeSequence to exclude the `0` alternative. Specifically, the 'overlap' comes from: LegacyOctalEscapeSequence :: OctalDigit [lookahead ∉ OctalDigit] so we replace that with: LegacyOctalEscapeSequence :: `0` [lookahead ∈ {`8`, `9`}] NonZeroOctalDigit [lookahead ∉ OctalDigit] (See Issue tc39#1975 for more details.) Resolves tc39#1975.

ljharb added the normative change Affects behavior required to correctly evaluate some ECMAScript source text label Feb 9, 2020

ljharb requested review from michaelficarra, syg, ljharb, bakkot and a team February 9, 2020 16:30

jmdyck force-pushed the make_B_literals_normative branch 2 times, most recently from bf7b1e2 to 7e3ff42 Compare February 24, 2020 02:26

ljharb requested review from waldemarhorwat and erights February 24, 2020 16:13

erights approved these changes Feb 24, 2020

View reviewed changes

jmdyck force-pushed the make_B_literals_normative branch from 7e3ff42 to 81800b3 Compare April 25, 2020 18:59

jmdyck mentioned this pull request Apr 27, 2020

B.1.2 (LegacyOctalEscapeSequences) could be clearer #1975

Closed

jmdyck force-pushed the make_B_literals_normative branch from 81800b3 to 6186f0d Compare October 17, 2020 02:27

jmdyck force-pushed the make_B_literals_normative branch from 6186f0d to d44b89b Compare November 30, 2020 02:31

jmdyck mentioned this pull request Jun 10, 2021

Are legacy escapes in strict mode code a valid extension? #2432

Open

jmdyck mentioned this pull request Jun 15, 2021

Normative: Make B.1 "Additional Syntax" normative #1651

Closed

jmdyck mentioned this pull request Jun 27, 2021

Editorial: Eliminate order-disambiguation from Annex B Pattern-grammar #2445

Open

ljharb force-pushed the master branch 3 times, most recently from 3d0c24c to 7a79833 Compare June 29, 2021 02:21

michaelficarra removed the editor call to be discussed in the next editor call label Jun 30, 2021

jmdyck force-pushed the make_B_literals_normative branch from ba4abee to c4f8a8e Compare July 11, 2021 02:22

ljharb reviewed Jul 11, 2021

View reviewed changes

jmdyck force-pushed the make_B_literals_normative branch from c4f8a8e to d3139c6 Compare July 24, 2021 01:27

michaelficarra approved these changes Jul 28, 2021

View reviewed changes

bakkot reviewed Jul 28, 2021

View reviewed changes

bakkot approved these changes Jul 28, 2021

View reviewed changes

bakkot added the editor call to be discussed in the next editor call label Jul 28, 2021

jmdyck added 3 commits August 12, 2021 14:18

Normative: Make B.1.1 "Numeric Literals" normative (tc39#1867)

4a2e017

(Part of Annex B reform, see PR tc39#1595.)

jmdyck force-pushed the make_B_literals_normative branch from d3139c6 to f79dfd2 Compare August 12, 2021 20:18

michaelficarra added ready to merge Editors believe this PR needs no further reviews, and is ready to land. and removed editor call to be discussed in the next editor call labels Aug 12, 2021

ljharb merged commit f79dfd2 into tc39:master Aug 15, 2021

jmdyck deleted the make_B_literals_normative branch August 16, 2021 00:15

mathiasbynens pushed a commit to mathiasbynens/ecma262 that referenced this pull request Oct 18, 2021

Normative: Make B.1.1 "Numeric Literals" normative (tc39#1867)

9dbd7f2

(Part of Annex B reform, see PR tc39#1595.)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Normative: Make B.1.{1,2} normative #1867

Normative: Make B.1.{1,2} normative #1867

jmdyck commented Feb 9, 2020

bakkot commented Feb 10, 2020

jmdyck commented Feb 24, 2020

littledan commented Feb 24, 2020

erights commented Feb 24, 2020

evilpie commented Feb 24, 2020

bakkot commented Feb 24, 2020

erights commented Feb 24, 2020

erights left a comment

jmdyck commented Apr 25, 2020

michaelficarra commented Oct 8, 2020

bakkot commented Oct 8, 2020

erights commented Oct 8, 2020

michaelficarra commented Oct 8, 2020

erights commented Oct 8, 2020

ljharb commented Oct 8, 2020

jmdyck commented Oct 17, 2020

jmdyck commented Jun 10, 2021

ljharb Jul 11, 2021

jmdyck Jul 24, 2021

ljharb Jul 11, 2021

jmdyck Jul 24, 2021

jmdyck commented Jul 24, 2021

bakkot Jul 28, 2021

jmdyck Jul 29, 2021

jmdyck commented Jul 29, 2021

bakkot commented Aug 11, 2021

jmdyck commented Aug 12, 2021

	<emu-note>In non-strict code, this syntax is legacy.</emu-note>
	<emu-note>In non-strict code, this syntax is Legacy.</emu-note>

Normative: Make B.1.{1,2} normative #1867

Normative: Make B.1.{1,2} normative #1867

Conversation

jmdyck commented Feb 9, 2020

bakkot commented Feb 10, 2020

jmdyck commented Feb 24, 2020

littledan commented Feb 24, 2020

erights commented Feb 24, 2020

evilpie commented Feb 24, 2020

bakkot commented Feb 24, 2020

erights commented Feb 24, 2020

erights left a comment

Choose a reason for hiding this comment

jmdyck commented Apr 25, 2020

michaelficarra commented Oct 8, 2020

bakkot commented Oct 8, 2020

erights commented Oct 8, 2020

michaelficarra commented Oct 8, 2020

erights commented Oct 8, 2020

ljharb commented Oct 8, 2020

jmdyck commented Oct 17, 2020

jmdyck commented Jun 10, 2021

ljharb Jul 11, 2021

Choose a reason for hiding this comment

jmdyck Jul 24, 2021

Choose a reason for hiding this comment

ljharb Jul 11, 2021

Choose a reason for hiding this comment

jmdyck Jul 24, 2021

Choose a reason for hiding this comment

jmdyck commented Jul 24, 2021

bakkot Jul 28, 2021

Choose a reason for hiding this comment

jmdyck Jul 29, 2021

Choose a reason for hiding this comment

jmdyck commented Jul 29, 2021

bakkot commented Aug 11, 2021

jmdyck commented Aug 12, 2021