Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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

このコミットは、Go言語のコンパイラ（gc）の一部であるsrc/cmd/gc/subr.cファイルに対する変更です。subr.cは、コンパイラのサブルーチンやユーティリティ関数、特にエラーハンドリングに関連する機能を提供していると考えられます。

コミット

このコミットは、Goコンパイラのエラーカウント方法を変更し、関数ごとのエラー数ではなく、累積エラー数を参照するように修正しています。これにより、コンパイル中に発生するエラーの総数が一定のしきい値（この場合は10）を超えた場合に、コンパイルプロセスを早期に終了させる判断がより適切に行われるようになります。

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

https://github.com/golang/go/commit/3208917d54fea665392b692dee1bf1a921510fc2

元コミット内容

gc: look at cumulative error count, not just per-function.

Not sure if this is what you'd really want. Maybe with a higher limit than 10
or perhaps keep checking nerrors > 10 per yyerror, but check the cumulative
after each function?

R=rsc
CC=golang-dev
https://golang.org/cl/5376064

変更の背景

Goコンパイラ（gc）は、コードのコンパイル中に様々なエラーを検出します。これらのエラーが多すぎると、それ以上コンパイルを続行しても意味がない場合や、コンパイラの処理が非常に遅くなる場合があります。そのため、コンパイラにはエラー数が一定のしきい値を超えた場合に、コンパイルを中断するメカニズムが組み込まれています。

このコミット以前は、エラーカウントが関数ごとに行われていた可能性があります。つまり、ある関数内で10個のエラーが発生した場合にのみコンパイルが中断される、といった挙動です。しかし、これは全体のエラー状況を正確に反映しているとは限りません。例えば、複数の異なる関数でそれぞれ9個のエラーが発生した場合、個々の関数ではしきい値を超えないためコンパイルは続行されますが、全体としては非常に多くのエラーが発生していることになります。

この変更の背景には、コンパイラのエラーハンドリングをより効率的かつ実用的にするという意図があります。累積エラー数をチェックすることで、コンパイラはプロジェクト全体でのエラーの深刻度をより正確に評価し、無駄なコンパイル処理を早期に停止できるようになります。コミットメッセージにある「Maybe with a higher limit than 10 or perhaps keep checking nerrors > 10 per yyerror, but check the cumulative after each function?」という記述は、エラーしきい値の調整や、エラーチェックのタイミングに関する議論が背景にあったことを示唆しています。これは、コンパイラのパフォーマンスとユーザーエクスペリエンスのバランスを取るための試みと言えます。

前提知識の解説

このコミットを理解するためには、以下の概念について知っておく必要があります。

  • Goコンパイラ (gc): Go言語の公式コンパイラです。ソースコードを機械語に変換する役割を担います。gcは、字句解析、構文解析、意味解析、中間コード生成、最適化、コード生成といった一連のフェーズを経てコンパイルを行います。
  • yyerror: コンパイラやパーサーの文脈でよく使われるエラー報告関数です。通常、構文解析中にエラーが検出された際に呼び出され、エラーメッセージを出力し、エラーカウンタをインクリメントします。yyerrorlは、行番号を引数として受け取るyyerrorのバリアントと考えられます。
  • nerrors: これは、現在のコンパイル単位（例えば、現在の関数やファイル）で発生したエラーの数を追跡するための変数である可能性が高いです。コンパイラがエラーを検出するたびにインクリメントされます。
  • nsavederrors: この変数は、以前のコンパイル単位（例えば、既に処理が完了した関数やファイル）で発生し、保存されたエラーの累積数を表していると考えられます。つまり、nerrorsが現在のエラー数を、nsavederrorsがそれまでの累積エラー数を保持していると推測できます。
  • debug['e']: これは、コンパイラのデバッグフラグの一つで、エラー関連のデバッグオプションが有効になっているかどうかを示すものです。!debug['e']は、エラーデバッグモードが有効でない場合に、エラー数のチェックを行うことを意味します。デバッグモードでは、通常、エラー数による早期終了は抑制され、より多くのエラー情報を収集できるようにします。
  • flusherrors(): エラーバッファをフラッシュし、蓄積されたエラーメッセージを出力する関数です。
  • errorexit(): エラーが発生したためにコンパイルプロセスを終了させる関数です。

コンパイラのエラーハンドリングでは、無限ループや過剰なエラーメッセージの出力によるリソース枯渇を防ぐために、エラー数の上限を設けることが一般的です。この上限を超えると、コンパイルは中断されます。

技術的詳細

このコミットの技術的な核心は、コンパイラのエラーカウントロジックの変更にあります。

変更前は、yyerrorおよびyyerrorl関数内で、nerrors変数が直接10以上になった場合にコンパイルを終了していました。これは、現在の処理スコープ（おそらく現在の関数）内でのエラー数のみを考慮していることを意味します。

// 変更前 (概念)
if(nerrors >= 10 && !debug['e']) {
    flusherrors();
    print("%L: too many errors\\n", line);
    errorexit();
}

変更後は、nerrorsに加えてnsavederrorsという変数を加算し、その合計が10以上になった場合にコンパイルを終了するように修正されています。

// 変更後 (概念)
if(nsavederrors+nerrors >= 10 && !debug['e']) {
    flusherrors();
    print("%L: too many errors\\n", line);
    errorexit();
}

この変更により、エラーのチェックが「現在の関数で発生したエラー数」から「コンパイル開始から現在までに発生した累積エラー数」へと変わります。

この変更の具体的な影響は以下の通りです。

  1. 早期終了の精度向上: コンパイラは、個々の関数でエラーが少なくても、全体としてエラーが多すぎる場合に早期にコンパイルを中断できるようになります。これにより、無駄なコンパイル時間を削減し、ユーザーに迅速なフィードバックを提供できます。
  2. リソース消費の抑制: 大量のエラーが発生するコードをコンパイルする際に、コンパイラが過剰なメモリやCPUリソースを消費するのを防ぎます。
  3. ユーザーエクスペリエンスの改善: ユーザーは、コンパイルが長時間実行された後に大量のエラーメッセージが表示されるよりも、早期に「エラーが多すぎる」という通知を受け取ることで、問題の特定と修正に早く取り掛かることができます。
  4. nsavederrorsの役割: nsavederrorsは、おそらく関数やファイルの境界を越えてエラー数を保持するためのメカニズムです。例えば、ある関数がコンパイルされ、その中でエラーが発生した場合、そのエラー数はnsavederrorsに加算され、次の関数のコンパイル時にはその累積値が考慮されるようになります。これにより、コンパイラ全体でのエラーの総数を正確に追跡できます。

この変更は、コンパイラの堅牢性と効率性を向上させるための、比較的小さながらも重要な改善と言えます。

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

--- a/src/cmd/gc/subr.c
+++ b/src/cmd/gc/subr.c
@@ -119,7 +119,7 @@ yyerrorl(int line, char *fmt, ...)\n \n \thcrash();\n \tnerrors++;\n-\tif(nerrors >= 10 && !debug['e']) {\n+\tif(nsavederrors+nerrors >= 10 && !debug['e']) {\n \t\tflusherrors();\n \t\tprint("%L: too many errors\\n", line);\n \t\terrorexit();\n@@ -187,7 +187,7 @@ yyerror(char *fmt, ...)\n \n \thcrash();\n \tnerrors++;\n-\tif(nerrors >= 10 && !debug['e']) {\n+\tif(nsavederrors+nerrors >= 10 && !debug['e']) {\n \t\tflusherrors();\n \t\tprint("%L: too many errors\\n", parserline());\n \t\terrorexit();\n```

## コアとなるコードの解説

変更は`src/cmd/gc/subr.c`ファイル内の`yyerrorl`関数と`yyerror`関数の2箇所で行われています。どちらの関数も、エラーが発生した際に呼び出されるエラー報告関数です。

1.  **`yyerrorl(int line, char *fmt, ...)` 関数内の変更**:
    *   変更前: `if(nerrors >= 10 && !debug['e']) {`
    *   変更後: `if(nsavederrors+nerrors >= 10 && !debug['e']) {`
    この行は、エラーが報告された後に、現在のエラー数`nerrors`が10以上であり、かつデバッグモードが有効でない場合に、コンパイルを終了するかどうかをチェックしています。変更後は、`nerrors`に加えて`nsavederrors`（保存された累積エラー数）を加算した値が10以上であるかをチェックするようになりました。

2.  **`yyerror(char *fmt, ...)` 関数内の変更**:
    *   変更前: `if(nerrors >= 10 && !debug['e']) {`
    *   変更後: `if(nsavederrors+nerrors >= 10 && !debug['e']) {`
    こちらも`yyerrorl`と同様に、エラー数のチェック条件が`nerrors`単独から`nsavederrors+nerrors`の合計へと変更されています。

これらの変更により、コンパイラは個々のエラー報告時（`yyerror`または`yyerrorl`が呼び出された時）に、現在のエラー数だけでなく、それまでに発生した累積エラー数も考慮して、コンパイルを早期に終了するかどうかを判断するようになります。これにより、コンパイル全体でのエラーの総数がしきい値を超えた場合に、より迅速にコンパイルを中断できるようになります。

## 関連リンク

*   Go Gerrit Change-Id: [https://golang.org/cl/5376064](https://golang.org/cl/5376064)

## 参考にした情報源リンク

*   特になし (提供された情報と一般的なコンパイラの知識に基づいて解説を生成しました。)