11 ECMAScript 言語: ソーステキスト (ECMAScript Language: Source Text)

11.1 ソーステキスト (Source Text)

構文 (Syntax)

SourceCharacter :: any Unicode code point

ECMAScript ソーステキスト は Unicode 符号位置の列である。ECMAScript 文法で許容される箇所であれば、U+0000 から U+10FFFF までのすべての Unicode 符号位置（サロゲートコードポイントを含む）が ECMAScript ソーステキスト中に現れうる。ECMAScript ソーステキストを格納または交換するために実際に用いられるエンコーディングは本仕様にとって本質的ではない。外部的なソーステキストのエンコーディングに関わらず、適合する ECMAScript 実装はソーステキストを、各 SourceCharacter が 1 つの Unicode 符号位置であるような同値の SourceCharacter 値列として処理する。適合実装はソーステキストの正規化を行うこと、または正規化を行っているかのように振る舞うことを要求されない。

結合文字シーケンスの構成要素は、利用者がその全体を 1 文字と捉える可能性があっても、個々の独立した Unicode 符号位置として扱われる。

Note

文字列リテラル、正規表現リテラル、テンプレートリテラル、および識別子においては、任意の Unicode 符号位置をその数値値を明示的に表す Unicode エスケープシーケンスで表現することもできる。コメント内では、そのようなエスケープシーケンスはコメントの一部として実質的に無視される。

ECMAScript は Unicode エスケープシーケンスの挙動において Java プログラミング言語と異なる。例えば Java プログラムにおいて Unicode エスケープ \u000A が単一行コメント内に現れた場合、それは行終端子（Unicode 符号位置 U+000A は LINE FEED (LF)）として解釈され、次の符号位置はそのコメントの一部ではなくなる。同様に Java の文字列リテラル内で \u000A が現れると、それは文字列リテラル内に許可されない行終端子として解釈される——文字列リテラルの値に LF を含めるには \u000A ではなく \n と書かなければならない。ECMAScript プログラムでは、コメント中の Unicode エスケープシーケンスが解釈されることは決してなく、従ってコメント終端に寄与しない。同様に、ECMAScript プログラム内の文字列リテラル中に現れる Unicode エスケープシーケンスは常にリテラル内容に寄与し、行終端子として、あるいは文字列リテラルを終端させうる符号位置として解釈されることはない。

11.1.1 静的セマンティクス: UTF16EncodeCodePoint ( cp: ユニコードコードポイント, ): 文字列

The abstract operation UNKNOWN takes UNPARSEABLE ARGUMENTS. It performs the following steps when called:

  1. 断言: 0 ≤ cp ≤ 0x10FFFF。
  2. cp ≤ 0xFFFF の場合、その数値が cp であるコードユニットのみからなる文字列値を返す。
  3. cu1 を floor((cp - 0x10000) / 0x400) + 0xD800 の数値を持つコードユニットとする。
  4. cu2 を ((cp - 0x10000) modulo 0x400) + 0xDC00 の数値を持つコードユニットとする。
  5. cu1 と cu2 を連結した文字列を返す。

11.1.2 静的セマンティクス: CodePointsToString ( text: ユニコードコードポイントの列, ): 文字列

The abstract operation UNKNOWN takes UNPARSEABLE ARGUMENTS. text を 6.1.4 で述べるように 文字列値へ変換する。 It performs the following steps when called:

  1. result を空文字列とする。
  2. text の各コードポイント cp について、次を行う
    1. result を result と UTF16EncodeCodePoint(cp) を連結した文字列に設定する。
  3. result を返す。

11.1.3 静的セマンティクス: UTF16SurrogatePairToCodePoint ( lead: コードユニット, trail: コードユニット, ): コードポイント

The abstract operation UNKNOWN takes UNPARSEABLE ARGUMENTS. UTF-16 サロゲートペアを構成する 2 つのコードユニットを 1 つのコードポイントへ変換する。 It performs the following steps when called:

  1. 断言: lead はリーディングサロゲート、trail はトレーリングサロゲートである。
  2. cp を (lead - 0xD800) × 0x400 + (trail - 0xDC00) + 0x10000 とする。
  3. コードポイント cp を返す。

11.1.4 静的セマンティクス: CodePointAt ( string: 文字列, position: 非負整数, ): フィールド [[CodePoint]]（コードポイント）、[[CodeUnitCount]]（正の整数）、[[IsUnpairedSurrogate]]（真偽値）を持つレコード

The abstract operation UNKNOWN takes UNPARSEABLE ARGUMENTS. string を 6.1.4 に記述される UTF-16 エンコードされたコードポイント列として解釈し、インデックス position のコードユニットから始まる 1 つのコードポイントを読み取る。 It performs the following steps when called:

  1. size を string の長さとする。
  2. 断言: position ≥ 0 かつ position < size。
  3. first を string のインデックス position のコードユニットとする。
  4. cp を first の数値を持つコードポイントとする。
  5. first がリーディングサロゲートでもトレーリングサロゲートでもない場合、
    1. レコード { [[CodePoint]]: cp, [[CodeUnitCount]]: 1, [[IsUnpairedSurrogate]]: false } を返す。
  6. first がトレーリングサロゲートまたは position + 1 = size の場合、
    1. レコード { [[CodePoint]]: cp, [[CodeUnitCount]]: 1, [[IsUnpairedSurrogate]]: true } を返す。
  7. second を string のインデックス position + 1 のコードユニットとする。
  8. second がトレーリングサロゲートでない場合、
    1. レコード { [[CodePoint]]: cp, [[CodeUnitCount]]: 1, [[IsUnpairedSurrogate]]: true } を返す。
  9. cp を UTF16SurrogatePairToCodePoint(first, second) に設定する。
  10. レコード { [[CodePoint]]: cp, [[CodeUnitCount]]: 2, [[IsUnpairedSurrogate]]: false } を返す。

11.1.5 静的セマンティクス: StringToCodePoints ( string: 文字列, ): コードポイントのリスト

The abstract operation UNKNOWN takes UNPARSEABLE ARGUMENTS. string を 6.1.4 に記述される UTF-16 エンコードされたユニコードテキストとして解釈した結果得られるユニコード符号位置列を返す。 It performs the following steps when called:

  1. codePoints を新しい空リストとする。
  2. size を string の長さとする。
  3. position を 0 とする。
  4. position < size の間、繰り返す：
    1. cp を CodePointAt(string, position) とする。
    2. codePoints に cp.[[CodePoint]] を追加する。
    3. position を position + cp.[[CodeUnitCount]] に設定する。
  5. codePoints を返す。

11.1.6 静的セマンティクス: ParseText ( sourceText: a String or a sequence of Unicode code points, goalSymbol: a nonterminal in one of the ECMAScript grammars, ): a Parse Node or a non-empty List of SyntaxError objects

The abstract operation UNKNOWN takes UNPARSEABLE ARGUMENTS. It performs the following steps when called:

  1. sourceText が文字列の場合、sourceText を StringToCodePoints(sourceText) に設定する。
  2. goalSymbol を目標記号として sourceText の構文解析を試み、構文解析結果について早期エラー条件を解析する。構文解析および早期エラー検出は、実装定義の方法でインターリーブしてもよい。
  3. 構文解析が成功し、早期エラーが検出されなかった場合、解析によって得られた構文木のルートにある Parse Node（goalSymbol のインスタンス）を返す。
  4. 構文解析エラーまたは早期エラーを表す一つ以上の SyntaxError オブジェクトのリストを返す。構文解析エラーまたは早期エラーが複数ある場合、リスト内のエラーオブジェクトの数や順序は実装定義だが、少なくとも一つは存在しなければならない。
 Note 1

ある箇所に早期エラーが存在し、後続位置に構文エラーが存在するテキストを考える。パース後に早期エラー検査を行う実装は構文エラーを報告し、早期エラー検査へ進まないかもしれない。両者をインターリーブする実装は早期エラーを報告し構文エラー検出を行わないかもしれない。第三の実装は両方のエラーを報告するかもしれない。これらの挙動はいずれも適合である。

 Note 2

17 も参照のこと。

11.2 ソースコードの種類 (Types of Source Code)

ECMAScript コードには 4 種類がある:

Note 1

関数コードは一般に Function 定義（15.2）、Arrow Function 定義（15.3）、Method 定義（15.4）、Generator Function 定義（15.5）、Async Function 定義（15.8）、Async Generator Function 定義（15.6）、および Async Arrow Function（15.9）の本体として提供される。関数コードはまた Function コンストラクタ（20.2.1.1）、GeneratorFunction コンストラクタ（27.3.1.1）、AsyncFunction コンストラクタ（27.7.1.1）、AsyncGeneratorFunction コンストラクタ（27.4.1.1）への引数から導出される。

 Note 2

BindingIdentifier を関数コードに含める実際上の効果は、その関数本体が "use strict" ディレクティブを含む関数の名前である BindingIdentifier に対して、周囲のコードが strict でない場合でも strict mode の Early Error が適用されることである。

11.2.1 ディレクティブプロローグと Use Strict ディレクティブ (Directive Prologues and the Use Strict Directive)

ディレクティブプロローグ (Directive Prologue) とは、FunctionBody, ScriptBody, または ModuleBody の先頭に現れる StatementListItem もしくは ModuleItem のうち、連続して並ぶ最長の ExpressionStatement 列であって、その列中の各 ExpressionStatement がセミコロンにより終端される（明示または自動セミコロン挿入 (12.10) により）純粋な StringLiteral トークンのみから構成されるものである。ディレクティブプロローグは空列であってもよい。

Use Strict ディレクティブ (Use Strict Directive) は、その StringLiteral が正確に "use strict" または 'use strict' のいずれかの符号位置列であるディレクティブプロローグ中の ExpressionStatement である。Use Strict ディレクティブは EscapeSequence や LineContinuation を含んではならない。

ディレクティブプロローグは複数の Use Strict ディレクティブを含んでもよい。ただし実装はこれが発生した場合に警告を出してよい。

Note

ディレクティブプロローグの ExpressionStatement は包含している生成規則の評価中に通常どおり評価される。実装は、Use Strict ディレクティブではないがディレクティブプロローグ中に現れる ExpressionStatement に対し実装独自の意味を定義してよい。適切な通知手段が存在する場合、実装はディレクティブプロローグ内で Use Strict ディレクティブではなく、かつ実装により意味が定義されていない ExpressionStatement に遭遇した際、警告を発するべきである。

11.2.2 Strict Mode コード (Strict Mode Code)

ECMAScript の構文単位は制限のない（非 strict）または strict モードの構文とセマンティクス（4.3.2）で処理されうる。コードは次の状況で strict mode code として解釈される:

strict mode code でない ECMAScript コードは non-strict code と呼ばれる。

11.2.2.1 静的セマンティクス: IsStrict ( node: a Parse Node, ): a Boolean

The abstract operation UNKNOWN takes UNPARSEABLE ARGUMENTS. It performs the following steps when called:

  1. node に一致するソーステキストが厳格モードコードである場合、true を返す。
  2. false を返す。

11.2.3 非 ECMAScript 関数 (Non-ECMAScript Functions)

ECMAScript 実装は、評価挙動が ECMAScript ソーステキスト以外のホスト定義実行可能コード形式で記述される関数エキゾチックオブジェクトの評価をサポートしてよい。ある関数オブジェクトが ECMAScript コード内で定義されたか、組み込み関数であるかは、その関数オブジェクトが呼び出す／呼び出される ECMAScript コードの観点からは観測できない。