Normative: Improve the "NotAmbiguous" grammar

[gibson042]

Technically normative in adding support for edge case like the following:

• HHMMSS[timeZoneName] where HHMMSS on its own is ambiguous with YYYYMM
  (e.g. "112312[America/New_York]")
• HHMM-HH[timeZoneName] where HHMM-HH on its own is ambiguous with YYYY-MM
  (e.g., "1001-12[-00:01]")

...but the polyfill already works like that.

[codecov]

Codecov Report

Merging #2284 (4af2c4a) into main (a4728e3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2284   +/-   ##
=======================================
  Coverage   95.03%   95.03%           
=======================================
  Files          20       20           
  Lines       10812    10812           
  Branches     1927     1927           
=======================================
  Hits        10275    10275           
  Misses        503      503           
  Partials       34       34           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[ptomato]

A few notes:

• I think it makes sense to split the initial editorial commits out into a separate PR, to avoid rebase trouble as much as possible.
• At some point in the past you suggested using early errors to simplify this part of the grammar, for which I opened Use early errors to simplify ISO 8601 grammar #1984. Should that still apply?
• I think this normative change subsumes Normative: Remove "60" from TimeMinuteNotValidDay #2279 and Normative: Add "22" to TimeHourNotValidMonth #2280, so we could close those. @anba do you agree?

[ptomato]

Is this a valid way of expressing this? I don't think I saw any existing examples of "but not" followed by a sequence; only single literals, nonterminals, or "one of" (e.g., "but not one of \, ', or LineTerminator")

[gibson042]

I believe so based on Grammar Notation («using the phrase “but not” and then indicating the expansions to be excluded»), but if not then I think it could instead use a negative lookahead like |ForStatement|:

Suggested change

	TimeZoneUTCOffset but not `-` TimeZoneUTCOffsetHour
	[lookahead != `-` TimeZoneUTCOffsetHour] TimeZoneUTCOffset

[anba]

I think this normative change subsumes #2279 and #2280, so we could close those. @anba do you agree?

Yes, agreed.

[gibson042]

I think it makes sense to split the initial editorial commits out into a separate PR, to avoid rebase trouble as much as possible.

Done: #2337 (and rebased this PR on top of it)

At some point in the past you suggested using early errors to simplify this part of the grammar, for which I opened #1984. Should that still apply?

Quite possibly. I'm in favor of any approach that gets this down to a small and comprehensible state.

[FrankYFTang]

when do you plan to push this to the spec? I was working on a cl to sync the v8 impl to the spec text in https://chromium-review.googlesource.com/c/v8/v8/+/3822342 but then syg asked me to hold till you land the changes to grammar and sync with that. So it will be nice if you can land this (and other parser changes already agreeed in 2022-07 meeting) ASAP

[ptomato]

These issues are waiting for corresponding test262 tests. For now, I've prioritized the PRs affecting the grammar above the other ones.

[ptomato]

This achieved consensus in July 2022. Tests are in tc39/test262#3641, so I think this is ready to go in.

[FrankYFTang]

@ptomato is there any other pending PR to merge which will change the ISO8601 Grammar after this before the next TC39?

[ptomato]

Yes, #2287 and #2345 are also awaiting tests.