C や C++ などの言語は、前方宣言に依存して、型または関数宣言の循環依存を解決します。C# では、宣言キャプチャ フェーズが 2 つのフェーズに分割されているため、これは不要になりました。1 つはシンボル名を取得し、もう 1 つは実際にシンボル宣言の構築を行います。
シンボル名取得フェーズの標準名はありますか? 宣言のキャプチャは、宣言内のすべてのシンボルの解決を含む従来のフェーズに残されると想定します
C や C++ などの言語は、前方宣言に依存して、型または関数宣言の循環依存を解決します。C# では、宣言キャプチャ フェーズが 2 つのフェーズに分割されているため、これは不要になりました。1 つはシンボル名を取得し、もう 1 つは実際にシンボル宣言の構築を行います。
シンボル名取得フェーズの標準名はありますか? 宣言のキャプチャは、宣言内のすべてのシンボルの解決を含む従来のフェーズに残されると想定します
C# コンパイラには、実際にはシンボル テーブルを作成する宣言フェーズがあります。すべてが大規模なスイープ フェーズで行われるわけではないため、Roslyn C# コンパイラはそれほど明確ではありません。代わりに、各シンボルはオンデマンドで個別に構築されます。ただし、構文内の型とメンバーの宣言がシンボルに変換されるステップがまだあります。バインド フェーズは論理的にこの後に続きます。ここでは、宣言されたシンボル テーブルを使用して、型とメンバー名への参照が解決されます。
これらの2つのフェーズが呼び出されると思います
構文解析は構文です。バインドとは、識別子と名前に意味を割り当てることです。
C++ でも同じことができます。しないように定義されているだけです。
私が探していたものを最もよく説明している Eric Lippert のブログ記事を見つけました。
C# 言語では、使用前に宣言を行う必要はありません。これは、ユーザーとコンパイラ ライターの 2 つの影響があります。ユーザーへの影響は、ファイルを変更したときに変更された IL だけを再コンパイルできないことです。アセンブリ全体が再コンパイルされます。幸いなことに、C# コンパイラは十分に高速であるため、これが大きな問題になることはめったにありません。(別の見方をすると、C# での再コンパイルの「粒度」は、ファイル レベルではなくプロジェクト レベルであるということです。)
コンパイラ作成者への影響は、「2 パス」コンパイラが必要になることです。最初のパスでは、宣言を探し、本体を無視します。C++ のヘッダーから取得したであろう宣言からすべての情報を収集したら、コードを 2 番目にパスして本体の IL を生成します。
...
次に、プログラム内のすべての名前空間と型宣言の場所に関するメモを作成する「宣言」パスを実行します。この時点で、最初のフェーズのソース コードの確認は完了です。後続のすべてのパスは、宣言から推定される「シンボル」のセットを対象としています。
次に、宣言されたすべての型の基本型に循環がないことを確認するパスを実行します。これを最初に行う必要があるのは、後続のすべてのパスで、サイクルを処理することなく型階層を上に移動できるようにする必要があるためです。
http://blogs.msdn.com/b/ericlippert/archive/2010/02/04/how-many-passes.aspx
.Net 5 では、Microsoft はサービスとしてのコンパイラである Roslyn を導入します。この Roslyn の概要では、コード生成前のコンパイラの 3 つのステップ (字句解析、構文解析、意味解析) について説明します。Roslyn プロジェクトの概要は、これらの説明を確認しますが、言葉の正確さは劣ります。