[インデックス 155] ファイルの概要

このコミットは、Go言語のテストスイートの一部である test/literal.go ファイルに対する変更です。このファイルは、Go言語における様々なリテラル（数値リテラル、文字列リテラルなど）の正しい解釈と動作を検証するためのテストケースを含んでいます。具体的には、uint64 型の最大値や、エスケープシーケンスを含む文字列リテラルの処理に関するバグが修正され、関連するテストが有効化されました。

コミット

このコミットは、Go言語の初期開発段階において、uint64 型の数値リテラルと特定の文字列エスケープシーケンス（特に \r）の処理に関するバグを修正し、それらのテストケースを有効化したものです。これにより、Goコンパイラがこれらのリテラルを正しく解釈できるようになったことを示しています。

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/4633a8ffe78070bcdfd9c764fad54ce4b79e93b8

元コミット内容

commit 4633a8ffe78070bcdfd9c764fad54ce4b79e93b8
Author: Rob Pike <r@golang.org>
Date:   Thu Jun 12 11:04:40 2008 -0700

    This test now runs correctly, with no bugs commented out
    
    SVN=122460
---
 test/literal.go | 10 +++++-----\n
 1 file changed, 5 insertions(+), 5 deletions(-)\n

diff --git a/test/literal.go b/test/literal.go
index bb35873862..becca6f9ac 100644
--- a/test/literal.go
+++ b/test/literal.go
@@ -99,10 +99,10 @@ func main() {\n 	assert(u22 == u23, "u22");\n \n 	// uint64\n-//BUG	var u30 uint64 = 0;\n-//BUG	var u31 uint64 = 1;\n-//BUG	var u32 uint64 = 18446744073709551615;\n-//BUG	var u33 uint64 = +18446744073709551615;\n+\tvar u30 uint64 = 0;\n+\tvar u31 uint64 = 1;\n+\tvar u32 uint64 = 18446744073709551615;\n+\tvar u33 uint64 = +18446744073709551615;\n \n \t// float\n \tvar f00 float = 3.14159;\n@@ -186,7 +186,7 @@ func main() {\n 	assert(s1[0] == 'h', "s1-0");\n 	assert(s1[4] == 0xc3, "s1-4");\n 	assert(s1[5] == 0xb4, "s1-5");\n-//	var s2 string = "\\a\\b\\f\\n\\r\\t\\v";  // BUG: \\r miscompiles\n+\tvar s2 string = "\\a\\b\\f\\n\\r\\t\\v";\n \n \tvar s00 string = "\\000";\n \tvar s01 string = "\\007";

変更の背景

このコミットは、Go言語の初期開発フェーズ、具体的には2008年6月に行われました。当時のGo言語はまだ実験的な段階であり、コンパイラやランタイムの基本的な機能が開発されている最中でした。

コミットメッセージにある「This test now runs correctly, with no bugs commented out」という記述と、コード内の「//BUG」コメントが削除されていることから、以下の背景が推測されます。

1. バグの存在: 以前のGoコンパイラには、uint64 型の最大値（18446744073709551615、これは 2^64 - 1 に相当）を正しく処理できない、または文字列リテラル内の特定のエスケープシーケンス（特にキャリッジリターン \r）を誤って解釈するというバグが存在していました。
2. テストの無効化: これらのバグのために、関連するテストケースは一時的にコメントアウトされ、テストスイートの実行時に失敗しないようにされていました。コード内の //BUG コメントは、そのテストが既知のバグのために無効化されていることを示すマーカーとして機能していました。
3. バグの修正とテストの有効化: このコミットが行われるまでに、Go言語の開発チームはこれらのバグを特定し、コンパイラまたは関連するパーサーのコードを修正しました。その結果、コメントアウトされていたテストケースが正しく実行されるようになったため、//BUG コメントを削除し、テストを有効化することが可能になりました。

この変更は、Go言語の型システムとリテラル処理の堅牢性を高める上で重要な一歩であり、言語の安定性と正確性を確保するための継続的な努力の一環です。

また、SVN=122460 という記述は、当時のGoプロジェクトがSubversion (SVN) をバージョン管理システムとして使用しており、このコミットがSVNリビジョン122460に対応することを示唆しています。後にGoプロジェクトはGitに移行しましたが、初期のコミットにはこのようなSVNリビジョン情報が含まれていることがあります。

前提知識の解説

1. Go言語の数値リテラルと型システム

• uint64 型: Go言語における符号なし64ビット整数型です。0から 2^64 - 1 までの値を表現できます。2^64 - 1 は 18446744073709551615 という非常に大きな数値になります。この型は、非常に大きな非負の整数値を扱う際に使用されます。
• 数値リテラル: ソースコードに直接記述される数値のことです。Goコンパイラは、これらのリテラルを適切な内部表現に変換する必要があります。特に、uint64 の最大値のような境界値の処理は、オーバーフローや精度に関するバグが発生しやすい箇所です。

2. Go言語の文字列リテラルとエスケープシーケンス

• 文字列リテラル: ダブルクォート (") またはバッククォート (`) で囲まれた文字の並びです。

• エスケープシーケンス: 文字列リテラル内で、特殊な意味を持つ文字や、直接記述できない文字（例: 改行、タブ、特定の制御文字）を表現するために使用される特殊な文字の組み合わせです。バックスラッシュ (\) で始まり、その後に特定の文字が続きます。

  • \a: アラート (ベル)
  • \b: バックスペース
  • \f: フォームフィード
  • \n: 改行 (ラインフィード)
  • \r: キャリッジリターン
  • \t: 水平タブ
  • \v: 垂直タブ
  • \\: バックスラッシュ自体
  • \": ダブルクォート
  • \': シングルクォート
  • \xhh: 16進数で指定されたバイト値 (例: \x41 は 'A')
  • \uhhhh: 16進数で指定されたUnicodeコードポイント (UTF-8エンコードされる)
  • \Uhhhhhhhh: 16進数で指定されたUnicodeコードポイント (UTF-8エンコードされる)
  • \ooo: 8進数で指定されたバイト値 (例: \000 はヌル文字)

  このコミットで問題となっていたのは、特に \r (キャリッジリターン) の処理です。キャリッジリターンは、カーソルを行の先頭に戻す制御文字であり、テキストファイルの改行コードとして \n と組み合わせて使用されることがあります（Windowsなど）。コンパイラがこれを正しく解釈できない場合、文字列の長さが誤って計算されたり、予期しない文字が挿入されたりする可能性があります。

3. テスト駆動開発とバグ修正のサイクル

このコミットは、ソフトウェア開発におけるテスト駆動開発（TDD）やバグ修正の典型的なサイクルを示しています。

1. バグの発見: 特定の入力（この場合はuint64の最大値や\rエスケープシーケンス）が期待通りに動作しないことが発見される。
2. テストケースの作成/特定: バグを再現するテストケースが作成されるか、既存のテストケースが特定される。
3. テストの失敗: バグが存在するため、テストケースは失敗する。
4. テストの無効化（一時的）: 開発の進行を妨げないように、失敗するテストケースが一時的にコメントアウトされるか、無効化される（このコミットでは//BUGコメントがその役割を果たしていた）。
5. バグの修正: 根本原因が特定され、コンパイラやランタイムのコードが修正される。
6. テストの有効化と成功: 修正後、無効化されていたテストケースが有効化され、正しく成功することを確認する。
7. コミット: 修正とテストの有効化がバージョン管理システムにコミットされる。

技術的詳細

このコミットの技術的詳細は、Go言語のコンパイラ（または字句解析器/パーサー）が、数値リテラルと文字列リテラルをどのように処理するかという点に集約されます。

uint64 リテラルの修正

Go言語のコンパイラは、ソースコード中の数値リテラルを読み取り、それを適切な内部表現（例えば、CPUのレジスタやメモリ上の64ビット整数）に変換する必要があります。uint64 の最大値 18446744073709551615 は、10進数で20桁にもなる非常に大きな数値です。

初期のコンパイラでは、この非常に大きな数値をパースする際に、以下のような問題が発生していた可能性があります。

• オーバーフローチェックの不備: 数値がターゲットの型（uint64）の最大値を超えていないかどうかのチェックが不十分だった。
• パーシングロジックの限界: 10進数の文字列をバイナリの数値に変換するアルゴリズムが、これほど大きな桁数の数値を正確に扱えなかった。例えば、中間計算で一時的にオーバーフローが発生したり、桁あふれを検出できなかったりするケースです。
• 符号の扱い: +18446744073709551615 のように明示的な正の符号が付いている場合と付いていない場合で、パーシングロジックに差異があった可能性。uint64 は符号なしなので、通常は符号は不要ですが、リテラルとして記述された場合に正しく処理される必要があります。

このコミットにより、Goコンパイラの数値リテラルパーサーが改善され、uint64 の最大値を含む有効なuint64リテラルが正確に解釈されるようになったことを示しています。これは、Go言語が大規模な数値計算やビット操作を正確に行うための基盤を固める上で不可欠な修正でした。

文字列リテラル内のエスケープシーケンス \r の修正

文字列リテラル内のエスケープシーケンスは、コンパイラの字句解析器（lexer）またはパーサー（parser）によって処理されます。字句解析器はソースコードをトークンに分割し、パーサーはそれらのトークンを構文木に構築します。エスケープシーケンスの処理は、通常、字句解析の段階で行われ、\r のようなシーケンスは単一のキャリッジリターン文字に変換されます。

コメント // BUG: \r miscompiles が示唆するように、以前のコンパイラでは \r エスケープシーケンスを正しく処理できていませんでした。考えられる原因としては、以下のようなものがあります。

• 誤った文字コード変換: \r が意図しないバイトシーケンスに変換されていた。
• 文字列長の誤計算: \r が正しく1文字としてカウントされず、文字列の長さが誤って計算されていた。
• パーサーの不整合: \r が特定の文脈で構文エラーを引き起こしたり、予期しないトークンとして扱われたりしていた。
• プラットフォーム依存の問題: 開発環境のOS（例えばWindows）とGoコンパイラの内部処理で、改行コードの解釈に不一致があった可能性。

この修正により、Goコンパイラは文字列リテラル内のすべての標準的なエスケープシーケンス、特に \r を、その意図する単一の制御文字として正確に解釈し、文字列の内部表現に含めることができるようになりました。これにより、Goプログラムが異なるプラットフォーム間で文字列を移植する際の互換性が向上し、文字列処理の信頼性が確保されます。

これらの修正は、Go言語のコンパイラが、言語仕様に厳密に従ってリテラルを解釈するための基本的な能力を確立する上で極めて重要でした。

コアとなるコードの変更箇所

diff --git a/test/literal.go b/test/literal.go
index bb35873862..becca6f9ac 100644
--- a/test/literal.go
+++ b/test/literal.go
@@ -99,10 +99,10 @@ func main() {\n 	assert(u22 == u23, "u22");\n \n 	// uint64\n-//BUG	var u30 uint64 = 0;\n-//BUG	var u31 uint64 = 1;\n-//BUG	var u32 uint64 = 18446744073709551615;\n-//BUG	var u33 uint64 = +18446744073709551615;\n+\tvar u30 uint64 = 0;\n+\tvar u31 uint64 = 1;\n+\tvar u32 uint64 = 18446744073709551615;\n+\tvar u33 uint64 = +18446744073709551615;\n \n \t// float\n \tvar f00 float = 3.14159;\n@@ -186,7 +186,7 @@ func main() {\n 	assert(s1[0] == 'h', "s1-0");\n 	assert(s1[4] == 0xc3, "s1-4");\n 	assert(s1[5] == 0xb4, "s1-5");\n-//	var s2 string = "\\a\\b\\f\\n\\r\\t\\v";  // BUG: \\r miscompiles\n+\tvar s2 string = "\\a\\b\\f\\n\\r\\t\\v";\n \n \tvar s00 string = "\\000";\n \tvar s01 string = "\\007";

コアとなるコードの解説

このコミットは、test/literal.go ファイル内の2つのセクションを変更しています。

1. uint64 型のテストケースの有効化

変更前:

//BUG	var u30 uint64 = 0;
//BUG	var u31 uint64 = 1;
//BUG	var u32 uint64 = 18446744073709551615;
//BUG	var u33 uint64 = +18446744073709551615;

変更後:

	var u30 uint64 = 0;
	var u31 uint64 = 1;
	var u32 uint64 = 18446744073709551615;
	var u33 uint64 = +18446744073709551615;

この変更では、uint64 型の変数宣言の行頭にあった //BUG コメントが削除されています。これは、以前はこれらの行がコンパイラのバグのためにコメントアウトされており、テストが実行されていなかったことを意味します。

• u30 と u31 はそれぞれ 0 と 1 という基本的な uint64 リテラルをテストしています。
• u32 は 18446744073709551615 という値をテストしています。これは 2^64 - 1 であり、uint64 型が表現できる最大値です。この値が正しくパースできるかどうかのテストは、コンパイラの数値リテラル処理の正確性にとって非常に重要です。
• u33 は +18446744073709551615 という値をテストしています。これは u32 と同じ値ですが、明示的な正の符号 (+) が付いています。Go言語では数値リテラルに符号を付けることができますが、uint 型では符号は意味を持ちません。しかし、コンパイラがこの形式をエラーなく受け入れ、正しくパースできることを確認するためのテストです。

//BUG コメントの削除は、これらの uint64 リテラルに関するコンパイラのバグが修正され、テストが期待通りに動作するようになったことを示しています。

2. 文字列リテラル内のエスケープシーケンス \r のテストケースの有効化

変更前:

//	var s2 string = "\a\b\f\n\r\t\v";  // BUG: \r miscompiles

変更後:

	var s2 string = "\a\b\f\n\r\t\v";

この変更では、s2 という文字列変数の宣言行がコメントアウトされていた状態から、コメントが解除されています。元のコメント // BUG: \r miscompiles が示すように、以前は文字列リテラル内のキャリッジリターン (\r) エスケープシーケンスの処理にバグがあり、このテストケースが正しく動作しなかったため、一時的に無効化されていました。

s2 の文字列リテラルには、Go言語でサポートされている様々なエスケープシーケンスが含まれています。

• \a: アラート
• \b: バックスペース
• \f: フォームフィード
• \n: 改行
• \r: キャリッジリターン
• \t: 水平タブ
• \v: 垂直タブ

このテストケースの有効化は、Goコンパイラが \r を含むこれらのエスケープシーケンスをすべて正しく解釈し、文字列の内部表現に変換できるようになったことを意味します。これにより、Go言語の文字列処理の信頼性と、異なる環境間での文字列リテラルの互換性が向上しました。

これらの変更は、Go言語のコンパイラが、言語仕様に定められたリテラルの構文とセマンティクスを正確に実装するための重要なマイルストーンを示しています。

関連リンク

• Go言語の仕様 (The Go Programming Language Specification):
  • Numeric literals
  • String literals
  • Escape sequences
• Go言語の初期開発に関する情報 (Go's history):
  • The Evolution of Go (Rob Pikeによるスライド)

参考にした情報源リンク

• GitHub: golang/go commit 4633a8ffe78070bcdfd9c764fad54ce4b79e93b8: https://github.com/golang/go/commit/4633a8ffe78070bcdfd9c764fad54ce4b79e93b8
• Go言語の公式ドキュメント (Go Programming Language): https://go.dev/
• Go言語の仕様 (The Go Programming Language Specification): https://go.dev/ref/spec
• Wikipedia: キャリッジリターン (Carriage return): https://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%A3%E3%83%AA%E3%83%83%E3%82%B8%E3%83%AA%E3%82%BF%E3%83%BC%E3%83%B3
• Wikipedia: Subversion (SVN): https://ja.wikipedia.org/wiki/Subversion
• Go言語の歴史に関する情報 (Go's history): https://go.dev/talks/2012/go-history.slide```markdown

[インデックス 155] ファイルの概要

このコミットは、Go言語のテストスイートの一部である test/literal.go ファイルに対する変更です。このファイルは、Go言語における様々なリテラル（数値リテラル、文字列リテラルなど）の正しい解釈と動作を検証するためのテストケースを含んでいます。具体的には、uint64 型の最大値や、エスケープシーケンスを含む文字列リテラルの処理に関するバグが修正され、関連するテストが有効化されました。

コミット

このコミットは、Go言語の初期開発段階において、uint64 型の数値リテラルと特定の文字列エスケープシーケンス（特に \r）の処理に関するバグを修正し、それらのテストケースを有効化したものです。これにより、Goコンパイラがこれらのリテラルを正しく解釈できるようになったことを示しています。

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/4633a8ffe78070bcdfd9c764fad54ce4b79e93b8

元コミット内容

commit 4633a8ffe78070bcdfd9c764fad54ce4b79e93b8
Author: Rob Pike <r@golang.org>
Date:   Thu Jun 12 11:04:40 2008 -0700

    This test now runs correctly, with no bugs commented out
    
    SVN=122460
---
 test/literal.go | 10 +++++-----\n
 1 file changed, 5 insertions(+), 5 deletions(-)\n

diff --git a/test/literal.go b/test/literal.go
index bb35873862..becca6f9ac 100644
--- a/test/literal.go
+++ b/test/literal.go
@@ -99,10 +99,10 @@ func main() {\n 	assert(u22 == u23, "u22");\n \n 	// uint64\n-//BUG	var u30 uint64 = 0;\n-//BUG	var u31 uint64 = 1;\n-//BUG	var u32 uint64 = 18446744073709551615;\n-//BUG	var u33 uint64 = +18446744073709551615;\n+\tvar u30 uint64 = 0;\n+\tvar u31 uint64 = 1;\n+\tvar u32 uint64 = 18446744073709551615;\n+\tvar u33 uint64 = +18446744073709551615;\n \n \t// float\n \tvar f00 float = 3.14159;\n@@ -186,7 +186,7 @@ func main() {\n 	assert(s1[0] == 'h', "s1-0");\n 	assert(s1[4] == 0xc3, "s1-4");\n 	assert(s1[5] == 0xb4, "s1-5");\n-//	var s2 string = "\\a\\b\\f\\n\\r\\t\\v";  // BUG: \\r miscompiles\n+\tvar s2 string = "\\a\\b\\f\\n\\r\\t\\v";\n \n \tvar s00 string = "\\000";\n \tvar s01 string = "\\007";

変更の背景

このコミットは、Go言語の初期開発フェーズ、具体的には2008年6月に行われました。当時のGo言語はまだ実験的な段階であり、コンパイラやランタイムの基本的な機能が開発されている最中でした。

コミットメッセージにある「This test now runs correctly, with no bugs commented out」という記述と、コード内の「//BUG」コメントが削除されていることから、以下の背景が推測されます。

1. バグの存在: 以前のGoコンパイラには、uint64 型の最大値（18446744073709551615、これは 2^64 - 1 に相当）を正しく処理できない、または文字列リテラル内の特定のエスケープシーケンス（特にキャリッジリターン \r）を誤って解釈するというバグが存在していました。
2. テストの無効化: これらのバグのために、関連するテストケースは一時的にコメントアウトされ、テストスイートの実行時に失敗しないようにされていました。コード内の //BUG コメントは、そのテストが既知のバグのために無効化されていることを示すマーカーとして機能していました。
3. バグの修正とテストの有効化: このコミットが行われるまでに、Go言語の開発チームはこれらのバグを特定し、コンパイラまたは関連するパーサーのコードを修正しました。その結果、コメントアウトされていたテストケースが正しく実行されるようになったため、//BUG コメントを削除し、テストを有効化することが可能になりました。

この変更は、Go言語の型システムとリテラル処理の堅牢性を高める上で重要な一歩であり、言語の安定性と正確性を確保するための継続的な努力の一環です。

また、SVN=122460 という記述は、当時のGoプロジェクトがSubversion (SVN) をバージョン管理システムとして使用しており、このコミットがSVNリビジョン122460に対応することを示唆しています。後にGoプロジェクトはGitに移行しましたが、初期のコミットにはこのようなSVNリビジョン情報が含まれていることがあります。

前提知識の解説

1. Go言語の数値リテラルと型システム

• uint64 型: Go言語における符号なし64ビット整数型です。0から 2^64 - 1 までの値を表現できます。2^64 - 1 は 18446744073709551615 という非常に大きな数値になります。この型は、非常に大きな非負の整数値を扱う際に使用されます。
• 数値リテラル: ソースコードに直接記述される数値のことです。Goコンパイラは、これらのリテラルを適切な内部表現に変換する必要があります。特に、uint64 の最大値のような境界値の処理は、オーバーフローや精度に関するバグが発生しやすい箇所です。

2. Go言語の文字列リテラルとエスケープシーケンス

• 文字列リテラル: ダブルクォート (") またはバッククォート (`) で囲まれた文字の並びです。

• エスケープシーケンス: 文字列リテラル内で、特殊な意味を持つ文字や、直接記述できない文字（例: 改行、タブ、特定の制御文字）を表現するために使用される特殊な文字の組み合わせです。バックスラッシュ (\) で始まり、その後に特定の文字が続きます。

  • \a: アラート (ベル)
  • \b: バックスペース
  • \f: フォームフィード
  • \n: 改行 (ラインフィード)
  • \r: キャリッジリターン
  • \t: 水平タブ
  • \v: 垂直タブ
  • \\: バックスラッシュ自体
  • \": ダブルクォート
  • \': シングルクォート
  • \xhh: 16進数で指定されたバイト値 (例: \x41 は 'A')
  • \uhhhh: 16進数で指定されたUnicodeコードポイント (UTF-8エンコードされる)
  • \Uhhhhhhhh: 16進数で指定されたUnicodeコードポイント (UTF-8エンコードされる)
  • \ooo: 8進数で指定されたバイト値 (例: \000 はヌル文字)

  このコミットで問題となっていたのは、特に \r (キャリッジリターン) の処理です。キャリッジリターンは、カーソルを行の先頭に戻す制御文字であり、テキストファイルの改行コードとして \n と組み合わせて使用されることがあります（Windowsなど）。コンパイラがこれを正しく解釈できない場合、文字列の長さが誤って計算されたり、予期しない文字が挿入されたりする可能性があります。

3. テスト駆動開発とバグ修正のサイクル

このコミットは、ソフトウェア開発におけるテスト駆動開発（TDD）やバグ修正の典型的なサイクルを示しています。

1. バグの発見: 特定の入力（この場合はuint64の最大値や\rエスケープシーケンス）が期待通りに動作しないことが発見される。
2. テストケースの作成/特定: バグを再現するテストケースが作成されるか、既存のテストケースが特定される。
3. テストの失敗: バグが存在するため、テストケースは失敗する。
4. テストの無効化（一時的）: 開発の進行を妨げないように、失敗するテストケースが一時的にコメントアウトされるか、無効化される（このコミットでは//BUGコメントがその役割を果たしていた）。
5. バグの修正: 根本原因が特定され、コンパイラやランタイムのコードが修正される。
6. テストの有効化と成功: 修正後、無効化されていたテストケースが有効化され、正しく成功することを確認する。
7. コミット: 修正とテストの有効化がバージョン管理システムにコミットされる。

技術的詳細

このコミットの技術的詳細は、Go言語のコンパイラ（または字句解析器/パーサー）が、数値リテラルと文字列リテラルをどのように処理するかという点に集約されます。

uint64 リテラルの修正

Go言語のコンパイラは、ソースコード中の数値リテラルを読み取り、それを適切な内部表現（例えば、CPUのレジスタやメモリ上の64ビット整数）に変換する必要があります。uint64 の最大値 18446744073709551615 は、10進数で20桁にもなる非常に大きな数値です。

初期のコンパイラでは、この非常に大きな数値をパースする際に、以下のような問題が発生していた可能性があります。

• オーバーフローチェックの不備: 数値がターゲットの型（uint64）の最大値を超えていないかどうかのチェックが不十分だった。
• パーシングロジックの限界: 10進数の文字列をバイナリの数値に変換するアルゴリズムが、これほど大きな桁数の数値を正確に扱えなかった。例えば、中間計算で一時的にオーバーフローが発生したり、桁あふれを検出できなかったりするケースです。
• 符号の扱い: +18446744073709551615 のように明示的な正の符号が付いている場合と付いていない場合で、パーシングロジックに差異があった可能性。uint64 は符号なしなので、通常は符号は不要ですが、リテラルとして記述された場合に正しく処理される必要があります。

このコミットにより、Goコンパイラの数値リテラルパーサーが改善され、uint64 の最大値を含む有効なuint64リテラルが正確に解釈されるようになったことを示しています。これは、Go言語が大規模な数値計算やビット操作を正確に行うための基盤を固める上で不可欠な修正でした。

文字列リテラル内のエスケープシーケンス \r の修正

文字列リテラル内のエスケープシーケンスは、コンパイラの字句解析器（lexer）またはパーサー（parser）によって処理されます。字句解析器はソースコードをトークンに分割し、パーサーはそれらのトークンを構文木に構築します。エスケープシーケンスの処理は、通常、字句解析の段階で行われ、\r のようなシーケンスは単一のキャリッジリターン文字に変換されます。

コメント // BUG: \r miscompiles が示唆するように、以前のコンパイラでは \r エスケープシーケンスを正しく処理できていませんでした。考えられる原因としては、以下のようなものがあります。

• 誤った文字コード変換: \r が意図しないバイトシーケンスに変換されていた。
• 文字列長の誤計算: \r が正しく1文字としてカウントされず、文字列の長さが誤って計算されていた。
• パーサーの不整合: \r が特定の文脈で構文エラーを引き起こしたり、予期しないトークンとして扱われたりしていた。
• プラットフォーム依存の問題: 開発環境のOS（例えばWindows）とGoコンパイラの内部処理で、改行コードの解釈に不一致があった可能性。

この修正により、Goコンパイラは文字列リテラル内のすべての標準的なエスケープシーケンス、特に \r を、その意図する単一の制御文字として正確に解釈し、文字列の内部表現に含めることができるようになりました。これにより、Goプログラムが異なるプラットフォーム間で文字列を移植する際の互換性が向上し、文字列処理の信頼性が確保されます。

これらの修正は、Go言語のコンパイラが、言語仕様に厳密に従ってリテラルを解釈するための基本的な能力を確立する上で極めて重要でした。

コアとなるコードの変更箇所

diff --git a/test/literal.go b/test/literal.go
index bb35873862..becca6f9ac 100644
--- a/test/literal.go
+++ b/test/literal.go
@@ -99,10 +99,10 @@ func main() {\n 	assert(u22 == u23, "u22");\n \n 	// uint64\n-//BUG	var u30 uint64 = 0;\n-//BUG	var u31 uint64 = 1;\n-//BUG	var u32 uint64 = 18446744073709551615;\n-//BUG	var u33 uint64 = +18446744073709551615;\n+\tvar u30 uint64 = 0;\n+\tvar u31 uint64 = 1;\n+\tvar u32 uint64 = 18446744073709551615;\n+\tvar u33 uint64 = +18446744073709551615;\n \n \t// float\n \tvar f00 float = 3.14159;\n@@ -186,7 +186,7 @@ func main() {\n 	assert(s1[0] == 'h', "s1-0");\n 	assert(s1[4] == 0xc3, "s1-4");\n 	assert(s1[5] == 0xb4, "s1-5");\n-//	var s2 string = "\\a\\b\\f\\n\\r\\t\\v";  // BUG: \\r miscompiles\n+\tvar s2 string = "\\a\\b\\f\\n\\r\\t\\v";\n \n \tvar s00 string = "\\000";\n \tvar s01 string = "\\007";

コアとなるコードの解説

このコミットは、test/literal.go ファイル内の2つのセクションを変更しています。

1. uint64 型のテストケースの有効化

変更前:

//BUG	var u30 uint64 = 0;
//BUG	var u31 uint64 = 1;
//BUG	var u32 uint64 = 18446744073709551615;
//BUG	var u33 uint64 = +18446744073709551615;

変更後:

	var u30 uint64 = 0;
	var u31 uint64 = 1;
	var u32 uint64 = 18446744073709551615;
	var u33 uint64 = +18446744073709551615;

この変更では、uint64 型の変数宣言の行頭にあった //BUG コメントが削除されています。これは、以前はこれらの行がコンパイラのバグのためにコメントアウトされており、テストが実行されていなかったことを意味します。

• u30 と u31 はそれぞれ 0 と 1 という基本的な uint64 リテラルをテストしています。
• u32 は 18446744073709551615 という値をテストしています。これは 2^64 - 1 であり、uint64 型が表現できる最大値です。この値が正しくパースできるかどうかのテストは、コンパイラの数値リテラル処理の正確性にとって非常に重要です。
• u33 は +18446744073709551615 という値をテストしています。これは u32 と同じ値ですが、明示的な正の符号 (+) が付いています。Go言語では数値リテラルに符号を付けることができますが、uint 型では符号は意味を持ちません。しかし、コンパイラがこの形式をエラーなく受け入れ、正しくパースできることを確認するためのテストです。

//BUG コメントの削除は、これらの uint64 リテラルに関するコンパイラのバグが修正され、テストが期待通りに動作するようになったことを示しています。

2. 文字列リテラル内のエスケープシーケンス \r のテストケースの有効化

変更前:

//	var s2 string = "\a\b\f\n\r\t\v";  // BUG: \r miscompiles

変更後:

	var s2 string = "\a\b\f\n\r\t\v";

この変更では、s2 という文字列変数の宣言行がコメントアウトされていた状態から、コメントが解除されています。元のコメント // BUG: \r miscompiles が示すように、以前は文字列リテラル内のキャリッジリターン (\r) エスケープシーケンスの処理にバグがあり、このテストケースが正しく動作しなかったため、一時的に無効化されていました。

s2 の文字列リテラルには、Go言語でサポートされている様々なエスケープシーケンスが含まれています。

• \a: アラート
• \b: バックスペース
• \f: フォームフィード
• \n: 改行
• \r: キャリッジリターン
• \t: 水平タブ
• \v: 垂直タブ

このテストケースの有効化は、Goコンパイラが \r を含むこれらのエスケープシーケンスをすべて正しく解釈し、文字列の内部表現に変換できるようになったことを意味します。これにより、Go言語の文字列処理の信頼性と、異なる環境間での文字列リテラルの互換性が向上しました。

これらの変更は、Go言語のコンパイラが、言語仕様に定められたリテラルの構文とセマンティクスを正確に実装するための重要なマイルストーンを示しています。

関連リンク

• Go言語の仕様 (The Go Programming Language Specification):
  • Numeric literals
  • String literals
  • Escape sequences
• Go言語の初期開発に関する情報 (Go's history):
  • The Evolution of Go (Rob Pikeによるスライド)

参考にした情報源リンク

• GitHub: golang/go commit 4633a8ffe78070bcdfd9c764fad54ce4b79e93b8: https://github.com/golang/go/commit/4633a8ffe78070bcdfd9c764fad54ce4b79e93b8
• Go言語の公式ドキュメント (Go Programming Language): https://go.dev/
• Go言語の仕様 (The Go Programming Language Specification): https://go.dev/ref/spec
• Wikipedia: キャリッジリターン (Carriage return): https://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%A3%E3%83%AA%E3%83%83%E3%82%B8%E3%83%AA%E3%82%BF%E3%83%BC%E3%83%B3
• Wikipedia: Subversion (SVN): https://ja.wikipedia.org/wiki/Subversion
• Go言語の歴史に関する情報 (Go's history): https://go.dev/talks/2012/go-history.slide