Skip to content

Commit

Permalink
Markup: change clause-ids to reflect changes in clause-titles
Browse files Browse the repository at this point in the history
... in previous commit.
  • Loading branch information
jmdyck committed Jul 18, 2021
1 parent 1050f46 commit e5a00ce
Showing 1 changed file with 12 additions and 12 deletions.
24 changes: 12 additions & 12 deletions spec.html
Original file line number Diff line number Diff line change
Expand Up @@ -499,7 +499,7 @@ <h1>Context-Free Grammars</h1>
<h1>The Lexical and RegExp Grammars</h1>
<p>A <em>lexical grammar</em> for ECMAScript is given in clause <emu-xref href="#sec-ecmascript-language-lexical-grammar"></emu-xref>. This grammar has as its terminal symbols Unicode code points that conform to the rules for |SourceCharacter| defined in <emu-xref href="#sec-source-text"></emu-xref>. It defines a set of productions, starting from the goal symbol |InputElementDiv|, |InputElementTemplateTail|, or |InputElementRegExp|, or |InputElementRegExpOrTemplateTail|, that describe how sequences of such code points are translated into a sequence of input elements.</p>
<p>Input elements other than white space and comments form the terminal symbols for the syntactic grammar for ECMAScript and are called ECMAScript <em>tokens</em>. These tokens are the reserved words, identifiers, literals, and punctuators of the ECMAScript language. Moreover, line terminators, although not considered to be tokens, also become part of the stream of input elements and guide the process of automatic semicolon insertion (<emu-xref href="#sec-automatic-semicolon-insertion"></emu-xref>). Simple white space and single-line comments are discarded and do not appear in the stream of input elements for the syntactic grammar. A |MultiLineComment| (that is, a comment of the form `/*`&hellip;`*/` that spans more than one line) is replaced by a single line terminator, which becomes part of the stream of input elements for the syntactic grammar.</p>
<p>A <em>RegExp grammar</em> for ECMAScript is given in <emu-xref href="#sec-patterns"></emu-xref>. This grammar also has as its terminal symbols the code points as defined by |SourceCharacter|. It defines a set of productions, starting from the goal symbol |Pattern|, that describe how sequences of code points are translated into regular expression patterns.</p>
<p>A <em>RegExp grammar</em> for ECMAScript is given in <emu-xref href="#sec-syntax-for-patterns"></emu-xref>. This grammar also has as its terminal symbols the code points as defined by |SourceCharacter|. It defines a set of productions, starting from the goal symbol |Pattern|, that describe how sequences of code points are translated into regular expression patterns.</p>
<p>Productions of the lexical and RegExp grammars are distinguished by having two colons &ldquo;<b>::</b>&rdquo; as separating punctuation. The lexical and RegExp grammars share some productions.</p>
</emu-clause>

Expand Down Expand Up @@ -16850,8 +16850,8 @@ <h1>Regular Expression Literals</h1>
<emu-note>
<p>A regular expression literal is an input element that is converted to a RegExp object (see <emu-xref href="#sec-regexp-regular-expression-objects"></emu-xref>) each time the literal is evaluated. Two regular expression literals in a program evaluate to regular expression objects that never compare as `===` to each other even if the two literals' contents are identical. A RegExp object may also be created at runtime by `new RegExp` or calling the RegExp constructor as a function (see <emu-xref href="#sec-regexp-constructor"></emu-xref>).</p>
</emu-note>
<p>The productions below describe the syntax for a regular expression literal and are used by the input element scanner to find the end of the regular expression literal. The source text comprising the |RegularExpressionBody| and the |RegularExpressionFlags| are subsequently parsed again using the more stringent ECMAScript Regular Expression grammar (<emu-xref href="#sec-patterns"></emu-xref>).</p>
<p>An implementation may extend the ECMAScript Regular Expression grammar defined in <emu-xref href="#sec-patterns"></emu-xref>, but it must not extend the |RegularExpressionBody| and |RegularExpressionFlags| productions defined below or the productions used by these productions.</p>
<p>The productions below describe the syntax for a regular expression literal and are used by the input element scanner to find the end of the regular expression literal. The source text comprising the |RegularExpressionBody| and the |RegularExpressionFlags| are subsequently parsed again using the more stringent ECMAScript Regular Expression grammar (<emu-xref href="#sec-syntax-for-patterns"></emu-xref>).</p>
<p>An implementation may extend the ECMAScript Regular Expression grammar defined in <emu-xref href="#sec-syntax-for-patterns"></emu-xref>, but it must not extend the |RegularExpressionBody| and |RegularExpressionFlags| productions defined below or the productions used by these productions.</p>
<h2>Syntax</h2>
<emu-grammar type="definition">
RegularExpressionLiteral ::
Expand Down Expand Up @@ -27021,7 +27021,7 @@ <h1>Forbidden Extensions</h1>
The behaviour of built-in methods which are specified in ECMA-402, such as those named `toLocaleString`, must not be extended except as specified in ECMA-402.
</li>
<li>
The RegExp pattern grammars in <emu-xref href="#sec-patterns"></emu-xref> and <emu-xref href="#sec-regular-expressions-patterns"></emu-xref> must not be extended to recognize any of the source characters A-Z or a-z as |IdentityEscape[+U]| when the <sub>[U]</sub> grammar parameter is present.
The RegExp pattern grammars in <emu-xref href="#sec-syntax-for-patterns"></emu-xref> and <emu-xref href="#sec-regular-expressions-patterns"></emu-xref> must not be extended to recognize any of the source characters A-Z or a-z as |IdentityEscape[+U]| when the <sub>[U]</sub> grammar parameter is present.
</li>
<li>
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.
Expand Down Expand Up @@ -32985,7 +32985,7 @@ <h1>RegExp (Regular Expression) Objects</h1>
<p>The form and functionality of regular expressions is modelled after the regular expression facility in the Perl 5 programming language.</p>
</emu-note>

<emu-clause id="sec-patterns">
<emu-clause id="sec-syntax-for-patterns" oldids="sec-patterns">
<h1>Syntax for Patterns</h1>
<p>The `RegExp` constructor applies the following grammar to the input pattern String. An error occurs if the grammar cannot interpret the String as an expansion of |Pattern|.</p>
<h2>Syntax</h2>
Expand Down Expand Up @@ -33551,7 +33551,7 @@ <h1>Static Semantics: CapturingGroupName</h1>
</emu-clause>
</emu-clause>

<emu-clause id="sec-pattern-semantics">
<emu-clause id="sec-runtime-semantics-for-patterns" oldids="sec-pattern-semantics">
<h1>Runtime Semantics for Patterns</h1>
<p>A regular expression pattern is converted into an Abstract Closure using the process described below. An implementation is encouraged to use more efficient algorithms than the ones listed below, as long as the results are the same. The Abstract Closure is used as the value of a RegExp object's [[RegExpMatcher]] internal slot.</p>
<p>A |Pattern| is either a BMP pattern or a Unicode pattern depending upon whether or not its associated flags contain a `u`. A BMP pattern matches against a String interpreted as consisting of a sequence of 16-bit values that are Unicode code points in the range of the Basic Multilingual Plane. A Unicode pattern matches against a String interpreted as consisting of Unicode code points encoded using UTF-16. In the context of describing the behaviour of a BMP pattern &ldquo;character&rdquo; means a single 16-bit Unicode BMP code point. In the context of describing the behaviour of a Unicode pattern &ldquo;character&rdquo; means a UTF-16 encoded code point (<emu-xref href="#sec-ecmascript-language-types-string-type"></emu-xref>). In either context, &ldquo;character value&rdquo; means the numeric value of the corresponding non-encoded code point.</p>
Expand Down Expand Up @@ -33619,8 +33619,8 @@ <h1>Pattern</h1>
1. Return a new Abstract Closure with parameters (_str_, _index_) that captures _m_ and performs the following steps when called:
1. Assert: Type(_str_) is String.
1. Assert: _index_ is a non-negative integer which is &le; the length of _str_.
1. If _Unicode_ is *true*, let _Input_ be ! StringToCodePoints(_str_). Otherwise, let _Input_ be a List whose elements are the code units that are the elements of _str_. _Input_ will be used throughout the algorithms in <emu-xref href="#sec-pattern-semantics"></emu-xref>. Each element of _Input_ is considered to be a character.
1. Let _InputLength_ be the number of characters contained in _Input_. This alias will be used throughout the algorithms in <emu-xref href="#sec-pattern-semantics"></emu-xref>.
1. If _Unicode_ is *true*, let _Input_ be ! StringToCodePoints(_str_). Otherwise, let _Input_ be a List whose elements are the code units that are the elements of _str_. _Input_ will be used throughout the algorithms in <emu-xref href="#sec-runtime-semantics-for-patterns"></emu-xref>. Each element of _Input_ is considered to be a character.
1. Let _InputLength_ be the number of characters contained in _Input_. This alias will be used throughout the algorithms in <emu-xref href="#sec-runtime-semantics-for-patterns"></emu-xref>.
1. Let _listIndex_ be the index into _Input_ of the character that was obtained from element _index_ of _str_.
1. Let _c_ be a new Continuation with parameters (_y_) that captures nothing and performs the following steps when called:
1. Assert: _y_ is a State.
Expand All @@ -33630,7 +33630,7 @@ <h1>Pattern</h1>
1. Return _m_(_x_, _c_).
</emu-alg>
<emu-note>
<p>A Pattern evaluates (&ldquo;compiles&rdquo;) to an Abstract Closure value. RegExpBuiltinExec can then apply this procedure to a String and an offset within the String to determine whether the pattern would match starting at exactly that offset within the String, and, if it does match, what the values of the capturing parentheses would be. The algorithms in <emu-xref href="#sec-pattern-semantics"></emu-xref> are designed so that compiling a pattern may throw a *SyntaxError* exception; on the other hand, once the pattern is successfully compiled, applying the resulting Abstract Closure to find a match in a String cannot throw an exception (except for any implementation-defined exceptions that can occur anywhere such as out-of-memory).</p>
<p>A Pattern evaluates (&ldquo;compiles&rdquo;) to an Abstract Closure value. RegExpBuiltinExec can then apply this procedure to a String and an offset within the String to determine whether the pattern would match starting at exactly that offset within the String, and, if it does match, what the values of the capturing parentheses would be. The algorithms in <emu-xref href="#sec-runtime-semantics-for-patterns"></emu-xref> are designed so that compiling a pattern may throw a *SyntaxError* exception; on the other hand, once the pattern is successfully compiled, applying the resulting Abstract Closure to find a match in a String cannot throw an exception (except for any implementation-defined exceptions that can occur anywhere such as out-of-memory).</p>
</emu-note>
</emu-clause>

Expand Down Expand Up @@ -34537,7 +34537,7 @@ <h1>
1. Assert: _parseResult_ is a Parse Node for |Pattern|.
1. Set _obj_.[[OriginalSource]] to _P_.
1. Set _obj_.[[OriginalFlags]] to _F_.
1. Set _obj_.[[RegExpMatcher]] to the Abstract Closure that evaluates _parseResult_ by applying the semantics provided in <emu-xref href="#sec-pattern-semantics"></emu-xref> using _patternCharacters_ as the pattern's List of |SourceCharacter| values and _F_ as the flag parameters.
1. Set _obj_.[[RegExpMatcher]] to the Abstract Closure that evaluates _parseResult_ by applying the semantics provided in <emu-xref href="#sec-runtime-semantics-for-patterns"></emu-xref> using _patternCharacters_ as the pattern's List of |SourceCharacter| values and _F_ as the flag parameters.
1. Perform ? Set(_obj_, *"lastIndex"*, *+0*<sub>𝔽</sub>, *true*).
1. Return _obj_.
</emu-alg>
Expand Down Expand Up @@ -45403,7 +45403,7 @@ <h1>HTML-like Comments</h1>

<emu-annex id="sec-regular-expressions-patterns">
<h1>Regular Expressions Patterns</h1>
<p>The syntax of <emu-xref href="#sec-patterns"></emu-xref> is modified and extended as follows. These changes introduce ambiguities that are broken by the ordering of grammar productions and by contextual information. When parsing using the following grammar, each alternative is considered only if previous production alternatives do not match.</p>
<p>The syntax of <emu-xref href="#sec-syntax-for-patterns"></emu-xref> is modified and extended as follows. These changes introduce ambiguities that are broken by the ordering of grammar productions and by contextual information. When parsing using the following grammar, each alternative is considered only if previous production alternatives do not match.</p>
<p>This alternative pattern grammar and semantics only changes the syntax and semantics of BMP patterns. The following grammar extensions include productions parameterized with the [U] parameter. However, none of these extensions change the syntax of Unicode patterns recognized when parsing with the [U] parameter present on the goal symbol.</p>
<h2>Syntax</h2>
<emu-grammar type="definition">
Expand Down Expand Up @@ -45558,7 +45558,7 @@ <h1>Static Semantics: CharacterValue</h1>

<emu-annex id="sec-regular-expression-patterns-semantics">
<h1>Pattern Semantics</h1>
<p>The semantics of <emu-xref href="#sec-pattern-semantics"></emu-xref> is extended as follows:</p>
<p>The semantics of <emu-xref href="#sec-runtime-semantics-for-patterns"></emu-xref> is extended as follows:</p>
<p>Within <emu-xref href="#sec-term"></emu-xref> reference to &ldquo;<emu-grammar>Atom :: `(` GroupSpecifier Disjunction `)`</emu-grammar> &rdquo; are to be interpreted as meaning &ldquo;<emu-grammar>Atom :: `(` GroupSpecifier Disjunction `)`</emu-grammar> &rdquo; or &ldquo;<emu-grammar>ExtendedAtom :: `(` Disjunction `)`</emu-grammar> &rdquo;.</p>

<p>Term (<emu-xref href="#sec-term"></emu-xref>) includes the following additional evaluation rules:</p>
Expand Down

0 comments on commit e5a00ce

Please sign in to comment.