これによりモジュールグラフが構成される。各パスの指している内容を(途中まで)確定させる。(RFC1561)こうして名前解決が終わると、その結果を織り込みながらAST(抽象構文木)をHIR(高レベル中間表現)に変換します。HIRはASTとよく似ていますが名前解決済みなので、後のフェーズは各パスが指すDefを簡単に特定できます。パスが指す実体(Def)がどこなのかを対応づけるのが名前解決です。型に相対して決まるものはこのフェーズでは解決できないので、途中まで解決した状態で進みます。次回は、モジュールグラフの構造を説明します。Rust2018以降、Rustのモジュールシステムは入門しやすく、かつマスターしにくくなりました。そこで本記事では、その両方を達成することを目指しました。同じテーマで、Rust2018を考慮して改めてまとめ直したものです。モジュールとはモジュールはRustのプログラムを分割する単位のひとつです。ワークスペース・クレート・モジュールという単位になっていると考えてください。ワークスペースは関連するライブラリ(クレート)をひとつにまとめたもので、通常1つのgitリポジトリに対応します。AWSクライアントライブラリであるrusoto/rusotoには1つのワークスペースがあり、その中にはAWSクライアントのコアライブラリと各サービスに対応するライブラリが存在しています。アップロードした時点でワークスペースというまとまりに意味はなくなります。(crate)は依存解決の単位です。クレート同士は一方通行の依存関係しか持てません(dev-dependenciesなどの例外あり)依存の方向がはっきりしている場合(BはAに依存するが、AはBに依存せずに単独でも使える)はクレートを分割するのがよいでしょう。並列コンパイラは実装途上なので、大きなプロジェクトで並列性を高める場合は依存関係を考慮してクレートを分割するのがセオリーです。集約するという構造になっています。モジュールはクレート内で機能を小さい単位にわけて整理したり、実装を隠蔽したりするために使います。1ファイルが1モジュールになるように書くのが一般的です。基本的にクレート全体がコンパイルされるので、スリム化には使えません。実際にプログラムを書き始めるときは、1モジュールから始めて、必要に応じてモジュール分割→クレート分割→リポジトリ(ワークスペース)分割という形が一般的かと思います。そのものずばりパスと呼びます。Rust2018で一様パスが導入されたRust2018にあわせてRFC2126で定められたモジュールシステムの改革が実装され、2015時点でのモジュールシステムの問題点が改善されました。互換性のために古い書き方も残されているので全体の仕組みは複雑になりましたが、イディオマティックなRustコードでのモジュールの動作はかなりわかりやすくなったのではないかと思います。