?um/p1-90`ECMAScript の
入力要素の識別がそれを消費する構文文法コンテキストに依存する状況がいくつか存在する。これは字句文法に複数の目標（goal）記号を必要とする。
複数の字句目標を用いることで自動セミコロン挿入に影響する字句的曖昧さが存在しないことを保証する。例えば、先頭に除算または除算代入、かつ先頭に
a = b
/hi/g.exec(c).map(d);a = b / hi / g.exec(c).map(d);Unicode 形式制御文字（すなわち Unicode 文字データベースにおける “Cf” カテゴリ、例えば LEFT-TO-RIGHT MARK や RIGHT-TO-LEFT MARK）は、上位プロトコル（マークアップ言語など）が存在しない場合にテキスト範囲の整形を制御するために使用される制御コードである。
編集および表示を容易にするため、ソーステキスト内で形式制御文字を許可することは有用である。すべての形式制御文字はコメント内、ならびに文字列リテラル、テンプレートリテラル、正規表現リテラル内で使用できる。
U+FEFF (ZERO WIDTH NO-BREAK SPACE) は主としてテキストの冒頭で Unicode であることを示し、テキストのエンコーディングとバイト順を検出するために用いられる形式制御文字である。この目的で用いられる <ZWNBSP> 文字は、ファイル連結の結果などとしてテキスト開始後にも現れることがある。
空白符号位置はソーステキストの可読性を高め、トークン（分割不可能な字句単位）を相互に分離するために使用されるが、それ以外の点では意味を持たない。空白符号位置は任意の 2 つのトークンの間および入力の開始・末尾に現れうる。空白符号位置は
ECMAScript の空白符号位置は
| Code Points | Name | Abbreviation |
|---|---|---|
U+0009
|
CHARACTER TABULATION | <TAB> |
U+000B
|
LINE TABULATION | <VT> |
U+000C
|
FORM FEED (FF) | <FF> |
U+FEFF
|
ZERO WIDTH NO-BREAK SPACE | <ZWNBSP> |
| 一般カテゴリ “Space_Separator” のいかなる符号位置 | <USP> |
U+0020 (SPACE) と U+00A0 (NO-BREAK SPACE) は <USP> の一部である。
空白符号位置と同様に、行終端子符号位置はソーステキストの可読性を高め、トークンを相互に分離するために使用される。しかし空白符号位置と異なり、行終端子は構文文法の振る舞いに影響を及ぼす。一般に、行終端子は任意の 2 つのトークン間に現れうるが、構文文法により禁止される箇所がいくつか存在する。行終端子は自動セミコロン挿入（
行終端子は
行終端子は正規表現において \s クラスによりマッチされる空白符号位置集合に含まれる。
ECMAScript の行終端子符号位置は
| Code Point | Unicode Name | Abbreviation |
|---|---|---|
U+000A
|
LINE FEED (LF) | <LF> |
U+000D
|
CARRIAGE RETURN (CR) | <CR> |
U+2028
|
LINE SEPARATOR | <LS> |
U+2029
|
PARAGRAPH SEPARATOR | <PS> |
コメントは単一行または複数行のいずれかである。複数行コメントは入れ子にできない。
単一行コメントは // マーカーから行末までのすべての符号位置で構成される。ただし行末の
コメントは空白のように振る舞い破棄されるが、
この節のいくつかの生成規則は
ハッシュバンコメントは位置依存であり、他の種類のコメントと同様に構文文法への入力要素列からは破棄される。
この規格は追加の特定符号位置を許可する: U+0024 (DOLLAR SIGN) および U+005F (LOW LINE) は
非終端記号
非終端記号 _ を導出する。
Unicode プロパティ “ID_Start” および “ID_Continue” の集合には、それぞれ “Other_ID_Start” および “Other_ID_Continue” プロパティを持つ符号位置が含まれる。
Unicode エスケープシーケンスは ` はいかなる符号位置も寄与しない。|UnicodeEscapeSequence| は、それが寄与する符号位置をエスケープ無しで書いた場合に無効となるような符号位置を |IdentifierName| に寄与するためには使用できない。言い換えると、 `
Unicode 標準に従い正規等価な 2 つの
The syntax-directed operation UNKNOWN takes UNPARSEABLE ARGUMENTS. It is defined piecewise over the following productions:
The syntax-directed operation UNKNOWN takes UNPARSEABLE ARGUMENTS. It is defined piecewise over the following productions:
キーワード (keyword) とは if, while, async, await など多数が含まれる。
予約語 (reserved word) とは識別子として使用できない if と while は予約語である。await は async 関数およびモジュール内でのみ予約される。async は予約されていないため、変数名やラベルとして制限なく使用できる。
この仕様は文法生成規則および早期エラールールの組み合わせを用いて、どの名前が有効な識別子でどれが予約語かを指定する。下記 await と yield を除くすべてのトークンは無条件に予約される。await と yield の例外は
常に識別子として許可されキーワードではないもの（Math, window, toString, _ など）;
決して識別子として許可されないもの（await と yield を除く
文脈的に識別子として許可されるもの（await と yield）;
let, static, implements, interface, package, private, protected, public;
常に識別子として許可されるが、特定の構文生成規則中で as, async, from, get, meta, of, set, target。
条件付きキーワード (conditional keyword) または 文脈的キーワード (contextual keyword) という語がしばしば最後の 3 つのカテゴリに属するキーワードを指し、これらは文脈によって識別子またはキーワードとして使用できる。
` |UnicodeEscapeSequence| を含み得るが、els\u{65}` のように書いて “else” という名前の変数を宣言することはできない。
enum は現時点で本仕様においてキーワードとして使用されていない。これは将来の言語拡張でキーワードとして使用するために予約された future reserved word である。
同様に、implements, interface, package, private, protected, public は
例えば: 3in はエラーであり、3 と in の 2 つの入力要素ではない。
数値リテラルは Number 型または BigInt 型の値を表す。
9 まで、指定通り 3,4,5,6,7,8,9。
A の MV は 10。
B の MV は 11。
C の MV は 12。
D の MV は 13。
E の MV は 14。
F の MV は 15。
The syntax-directed operation UNKNOWN takes UNPARSEABLE ARGUMENTS. It is defined piecewise over the following productions:
文字列リテラルは単一または二重引用符で囲まれた 0 個以上の Unicode 符号位置である。Unicode 符号位置はエスケープシーケンスで表すこともできる。閉じ引用符、U+005C (REVERSE SOLIDUS), U+000D (CARRIAGE RETURN), U+000A (LINE FEED) 以外のすべての符号位置は文字列リテラル内にリテラルに記述可能である。任意の符号位置はエスケープシーケンスの形で出現可能である。文字列リテラルは ECMAScript String 値へと評価される。これらの String 値を生成する際、Unicode 符号位置は
非終端
<LF> と <CR> は \n や \u000A などのエスケープシーケンスを用いることである。
文字列リテラルは囲むコードを strict mode にする Use Strict ディレクティブより前に現れる可能性があるため、実装はそのようなリテラルに対して上記規則を適用する際注意しなければならない。例えば次のソーステキストは構文エラーを含む:
function invalid() { "\7"; "use strict"; }The syntax-directed operation UNKNOWN takes UNPARSEABLE ARGUMENTS.
文字列リテラルは String 型の値を表す。SV は文字列リテラルの各部分に再帰的に適用され String 値を生成する。この過程で、文字列リテラル内の一部の Unicode 符号位置は下記または
| Escape Sequence | Code Unit Value | Unicode Character Name | Symbol |
|---|---|---|---|
\\b
|
0x0008
|
BACKSPACE | <BS> |
\\t
|
0x0009
|
CHARACTER TABULATION | <HT> |
\\n
|
0x000A
|
LINE FEED (LF) | <LF> |
\\v
|
0x000B
|
LINE TABULATION | <VT> |
\\f
|
0x000C
|
FORM FEED (FF) | <FF> |
\\r
|
0x000D
|
CARRIAGE RETURN (CR) | <CR> |
\\"
|
0x0022
|
QUOTATION MARK |
"
|
\\'
|
0x0027
|
APOSTROPHE |
'
|
\\\\
|
0x005C
|
REVERSE SOLIDUS |
\\
|
以下の生成規則は正規表現リテラルの構文を記述し、入力要素スキャナが正規表現リテラルの終端を見つけるために用いられる。
実装は
正規表現リテラルは空にできない。空の正規表現リテラルを表す代わりに // は単一行コメントを開始する。空の正規表現を指定するには /(?:)/ を用いる。
The syntax-directed operation UNKNOWN takes UNPARSEABLE ARGUMENTS. It is defined piecewise over the following productions:
The syntax-directed operation UNKNOWN takes UNPARSEABLE ARGUMENTS. It is defined piecewise over the following productions:
The syntax-directed operation UNKNOWN takes UNPARSEABLE ARGUMENTS. テンプレートリテラル構成要素は TV により String 型の値として解釈される。TV はテンプレートオブジェクトのインデックス付き構成要素（テンプレート値）を構成する。TV ではエスケープシーケンスはその Unicode 符号位置を UTF-16 のコードユニットに置換される。
The syntax-directed operation UNKNOWN takes UNPARSEABLE ARGUMENTS. テンプレートリテラル構成要素は TRV により String 型の値として解釈される。TRV はテンプレートオブジェクトの raw 構成要素（テンプレート raw 値）を構築する。TRV は TV と似ているが、TRV ではエスケープシーケンスは字面通りのコード単位として扱われる点が異なる。
TV は
ほとんどの ECMAScript 文および宣言はセミコロンで終端されなければならない。これらのセミコロンは常に明示的に記述できる。利便性のため、特定の状況ではそれらを省略できる。これらの状況ではソースコードトークン列へ自動的にセミコロンが挿入されると記述される。
以下の規則において “token” は
セミコロン挿入には 3 つの基本規則がある:
ソーステキストを左から右へパースする際、いかなる文法生成規則でも許可されないトークン（違反トークン）に遭遇したとき、以下のいずれかが真ならその違反トークンの前にセミコロンが自動挿入される:
} である。
) であり、挿入されたセミコロンが do-while 文 (ただし上記規則には更に支配的な条件がある: セミコロンが自動挿入された結果それが空文としてパースされる場合、またはそのセミコロンが for 文ヘッダ内の 2 つのセミコロンの一つになる場合（
以下は文法中の唯一の制限付き生成規則である:
これら制限付き生成規則の実際的効果は次の通り:
++ または -- が出現し、直前トークンとの間に 1 つ以上の continue, break, return, throw, yield トークンに続いて => の間に => は構文エラーとなる。
async の後に function や ( が続く前に改行がある場合、セミコロンが挿入され async は後続と同じ式／クラス要素と扱われない。
async の後に * が来る場合、セミコロンが挿入され * は構文エラーとなる。
実務上の指針:
++ / -- はオペランドと同じ行に置く。
return / throw / yield の後に続く式は同じ行で開始する。
break / continue の => は同じ行に置く。
async は直後のトークンと同じ行に置く。
次のソース
{ 1 2 } 3は自動セミコロン挿入規則を考慮しても ECMAScript 文法の妥当な文ではない。対照的に次のソース
{ 1
2 } 3も妥当ではないが、自動セミコロン挿入により以下に変換される:
{ 1
;2 ;} 3;これは妥当な ECMAScript 文である。
次のソース
for (a; b
)は妥当ではなく、自動セミコロン挿入で変更されない。これは for 文ヘッダのセミコロンが必要であり、自動挿入は for ヘッダ内 2 つのセミコロンのいずれも挿入しないためである。
次のソース
return
a + bは次に変換される:
return;
a + b;a + b は return 文で返される値として扱われない。return トークンとそれに続く式を分離するためである。
次のソース
a = b
++cは以下に変換される:
a = b;
++c;++ トークンは変数 b への後置演算子として扱われない。b と ++ の間に
次のソース
if (a > b)
else c = dは妥当ではなく、else トークンの前には自動セミコロン挿入による変化は起こらない。文法生成規則が適用できない地点ではあるが、挿入された場合空文になるため。
次のソース
a = b + c
(d + e).print()は自動セミコロン挿入で変換されない。2 行目冒頭の括弧付き式は関数呼び出しの引数リストと解釈できるためである:
a = b + c(d + e).print()代入文が左括弧で始まらなければならない状況では、自動セミコロン挿入に頼らず前の文末に明示的なセミコロンを置くべきである。
ECMAScript プログラムは自動セミコロン挿入に依存することで非常に少ないセミコロンで書くことができる。上述のようにセミコロンはすべての改行で挿入されるわけではなく、挿入は複数トークンにまたがる。
ECMAScript に新しい構文機能が追加されると、追加の構文生成規則が導入され、自動セミコロン挿入に依存する行がパース時に使用する生成規則を変化させる可能性がある。
本節では、前に現れるソーステキストによってセミコロンが挿入されるか否かが変わりうる箇所を興味深いケースとみなす。本バージョンでの自動セミコロン挿入のいくつかの興味深いケースを以下で説明する。
()。セミコロンがなければ 2 行は [)。セミコロンがなければ 2 行は `)。セミコロンがなければ 2 行は前の式を + または -。セミコロンがなければ 2 行は対応する二項演算子の使用と解釈され得る。/ ECMAScript には “[no
以下では本バージョンの “[no