Repository navigation
Editorial: Prepare Annex B for ecmarkup linting - #3932
Conversation
|
The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/3932 and as multiple pages at https://tc39.es/ecma262/pr/3932/multipage . |
There was a problem hiding this comment.
The preamble for ContainsUndefinedBreakTarget needs to mention the _labelSet_ parameter.
| 1. Let _year_ be ? ToNumber(_year_). | ||
| 1. If _time_ is *NaN*, set _time_ to *+0*<sub>𝔽</sub>; else set _time_ to LocalTime(_time_). | ||
| 1. Let _fullYear_ be MakeFullYear(_year_). | ||
| 1. Let _fullYear_ be MakeFullYear(? ToNumber(_year_)). |
There was a problem hiding this comment.
This seems unrelated to the point of the PR?
There was a problem hiding this comment.
It's to avoid re-declaring the _year_ variable
There was a problem hiding this comment.
Oh, I guess it's for more general linting.
| <p>The semantics of <emu-xref href="#sec-compiletocharset"></emu-xref> is extended as follows:</p> | ||
|
|
||
| <p>The following two rules replace the corresponding rules of CompileToCharSet.</p> | ||
| <p>The following two rules replace the corresponding rules of CompileToCharSet with parameter _regexpRecord_.</p> |
There was a problem hiding this comment.
"replace ... with ..." is a bit of a garden path.
One alternative would be to use (here and elsewhere) a parenthesized parameter list:
| <p>The following two rules replace the corresponding rules of CompileToCharSet with parameter _regexpRecord_.</p> | |
| <p>The following two rules replace the corresponding rules of CompileToCharSet ( _regexpRecord_ ).</p> |
Possibly better (again, here and elsewhere) would be to move the parameter list into the section's heading. (Though that doesn't work for "Initializers in ForIn Statement Heads" as currently structured.)
There was a problem hiding this comment.
I've added two commits, the first one covering this specific consistency and the second one going a little bit farther for ParsePattern.
1d27476 to
1ba00ca
Compare
jmdyck
left a comment
There was a problem hiding this comment.
Also, there's the (pre-existing) inconsistency between "semantics is" and "semantics are" in the prose being touched.
Ref tc39/ecmarkup#716 - Try for more consistency in the Annex B SDO modifications - Use INS tags to highlight Annex B ParsePattern modifications like we already do for Regular Expression Early Errors
58845fb to
808af17
Compare
Ref tc39/ecmarkup#716