コンパイラをビルドして実行する方法

コンパイラは x.py というツールを使用してビルドされます。 これを実行するには Python がインストールされている必要があります。

クイックスタート

コンパイラを実行できるようにするための、より簡潔なクイックスタートについては、クイックスタートを参照してください。

ソースコードを取得する

メインのリポジトリは rust-lang/rust です。 これには、コンパイラ、 標準ライブラリ（core、alloc、test、proc_macro などを含む）、 および多数のツール（例: rustdoc、ブートストラップ基盤など）が含まれています。

rustc に取り組む最初のステップは、リポジトリをクローンすることです。

git clone https://github.com/rust-lang/rust.git
cd rust

リポジトリを部分クローンする

リポジトリのサイズが大きいため、遅いインターネット接続でクローンすると長い時間がかかることがあり、 すべてのファイルとディレクトリの完全な履歴を保存するためのディスク容量も必要です。 代わりに、git に 部分クローン を実行するよう指示できます。これにより、現在のファイル内容のみを完全に取得し、 たとえば履歴をさかのぼるときに、追加のファイル内容を自動的に取得します。 すべての git コマンドは通常どおり動作し続けますが、まだ読み込まれていない履歴上の地点を参照するには インターネット接続が必要になります。

git clone --filter='blob:none' https://github.com/rust-lang/rust.git
cd rust

注: このリンク では、この種のチェックアウトについてより詳しく説明しており、shallow clone などの 他のモードとの比較も行っています。

リポジトリを shallow clone する

部分クローンより古い代替手段として、代わりにリポジトリを shallow clone する方法があります。 そのためには、git clone コマンドで --depth N オプションを使用できます。 これは、git に「shallow clone」を実行するよう指示し、リポジトリをクローンしますが、 最後の N 個のコミットまで履歴を切り詰めます。

--depth 1 を渡すと、git はリポジトリをクローンしますが、履歴を main ブランチ上の最新の コミットまで切り詰めます。これは通常、ソースコードの閲覧やコンパイラのビルドには十分です。

git clone --depth 1 https://github.com/rust-lang/rust.git
cd rust

注: shallow clone では、実行できる git コマンドが制限されます。 コンパイラに取り組み、貢献するつもりであれば、 通常は上記のようにリポジトリを完全にクローンするか、 代わりに部分クローンを実行することが推奨されます。

たとえば、git bisect と git blame にはコミット履歴へのアクセスが必要なため、 リポジトリが --depth 1 でクローンされている場合は動作しません。

x.py とは何か？

x.py は rust リポジトリのビルドツールです。 ドキュメントのビルド、テストの実行、コンパイラと標準ライブラリのビルドを行えます。

この章では、生産的に作業するための基本に焦点を当てていますが、 x.py についてさらに学びたい場合は、この章を読んでください。

また、x.py ではなく x を使用することが推奨されます。その理由は次のとおりです。

./x は、すべてのシステムで動作する可能性が最も高いです（Unix では Python バージョン検出を行うシェルスクリプトを実行し、 Windows ではおそらく powershell スクリプトを実行します。多くの場合単に ファイルをエディタで開いてしまう ./x.py よりも、壊れにくいのは確かです）。¹

（x.ps1 のような、プラットフォーム関連のスクリプトは x.py の周辺にあります）

これは絶対的なものではないことに注意してください。 たとえば、Win10 上の VSCode で Nushell を使用している場合、 x または ./x と入力しても、プログラムが起動されるのではなく、依然として x.py がエディタで開かれます。

このガイドの残りの部分では、x.py を直接ではなく x を使用します。 次のコマンドは、

./x check

次のように置き換えることができます。

./x.py check

x.py を実行する

x.py コマンドは、ほとんどの Unix システムで次の形式で直接実行できます。

./x <subcommand> [flags]

これは、ドキュメントと例が x.py を実行していると想定している方法です。 いくつかの代替方法は次のとおりです。

# 必要な `python3` コマンドがない場合の Unix シェルで
./x <subcommand> [flags]

# Windows Powershell で（powershell がスクリプトを実行するように構成されている場合）
./x <subcommand> [flags]
./x.ps1 <subcommand> [flags]

# Windows コマンド プロンプトで（.py ファイルが Python を実行するように構成されている場合）
x.py <subcommand> [flags]

# Python を自分で実行することもできます。例:
python x.py <subcommand> [flags]

Windows では、Powershell コマンドによって次のようなエラーが表示される場合があります。

PS C:\Users\vboxuser\rust> ./x
./x : File C:\Users\vboxuser\rust\x.ps1 cannot be loaded because running scripts is disabled on this system. For more
information, see about_Execution_Policies at https://go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ ./x
+ ~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

powershell がローカルスクリプトを実行できるようにすることで、このエラーを回避できます。

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

x.py を少し便利に実行する

src/tools/x には、x.py をラップする x というバイナリがあります。 これが行うことは x.py の実行だけですが、システム全体にインストールでき、チェックアウトの任意のサブディレクトリから実行できます。 また、使用する適切なバージョンの python も検索します。

cargo install --path src/tools/x でインストールできます。

これが別のグローバルにインストールされたバイナリユーティリティであることを明確にしておくと、これは x.py とは何か セクションで説明したものに似ていますが、 プラットフォーム関連のスクリプトを実行するためにシェルを呼び出すのではなく、 独立したプロセスとして動作して x.py を実行します。

bootstrap.toml を作成する

まず、./x setup を実行して compiler のデフォルトを選択します。 これにより、いくつかの初期化が行われ、妥当なデフォルトを備えた bootstrap.toml が作成されます。 別のデフォルトを使用する場合（コンパイラ以外の rust の領域、 たとえば rustdoc に貢献したい場合には、おそらくそうすることになるでしょう）、 そのデフォルトに関する情報（src/bootstrap/defaults にあります）を必ず読んでください。 他のデフォルトではビルドプロセスが異なる場合があります。

あるいは、bootstrap.toml を手で書くこともできます。 利用可能なすべての設定とそれらの働きについては、bootstrap.example.toml を参照してください。 変更する一般的な設定については、src/bootstrap/defaults を参照してください。 すでに rustc をビルド済みで、LLVM に関連する設定を変更した場合、その後の設定変更を有効にするには ./x clean --all を実行しなければならないことがあります。 ./x clean では LLVM は再ビルドされないことに注意してください。

一般的な x コマンド

ここでは、rustc、std、rustdoc、およびその他のツールで作業する際に 最もよく使われる x コマンドの基本的な呼び出しを示します。

記載されているとおり、これらのコマンドは妥当な出発点です。 ただし、本格的な開発作業のために学んでおく価値のある追加のオプションや引数が、 それぞれにあります。 特に、./x build と ./x test には、 コードの一部だけをコンパイルまたはテストする方法が多数用意されており、多くの時間を節約できます。

また、x は compiler、library、 および src/tools ディレクトリに対するあらゆる種類のパスサフィックスをサポートしていることにも注意してください。 そのため、x test src/tools/tidy の代わりに単に x test tidy を実行できます。 また、x build library/std の代わりに x build std を実行できます。

詳細については、テスト と rustdoc の章を参照してください。

コンパイラをビルドする

ビルドには比較的大きなストレージ容量が必要になることに注意してください。 コンパイラをビルドするには、10 または 15 ギガバイト以上を利用できるようにしておくとよいでしょう。

bootstrap.toml を作成したら、x を実行する準備が整います。 ここには多くのオプションがありますが、ローカルコンパイラをビルドする際の おそらく最適な「定番」コマンドから始めましょう。

./x build library

このコマンドが行うことは次のとおりです。

• stage0 コンパイラと stage0 std を使用して rustc をビルドします。
• 直前にビルドされた stage1 コンパイラで library（標準ライブラリ）をビルドします。
• stage1 コンパイラと stage1 標準ライブラリを含む、動作する stage1 sysroot を組み立てます。

この最終成果物（stage1 コンパイラ + そのコンパイラを使用してビルドされた libs）が、 他の Rust プログラムをビルドするために必要なものです（#![no_std] または #![no_core] を使用する場合を除きます）。

stage1 std のビルドがボトルネックになることにおそらく気づくでしょうが、 心配はいりません。（ハック的な）回避策があります… std の再ビルドを避けるセクションを参照してください。

完全なビルドが必要ない場合もあります。 メソッド名の変更や、何らかの関数のシグネチャ変更のような、 「型に基づくリファクタリング」を行う場合は、代わりに ./x check を使用すると、はるかに高速にビルドできます。

このコマンド全体で得られるのは、完全な rustc ビルドの一部だけであることに注意してください。 完全な rustc ビルド（./x build --stage 2 rustc で得られるもの）には、さらにかなり多くの手順があります。

• stage1 コンパイラで rustc をビルドします。
  • ここで生成されるコンパイラは「stage2」コンパイラと呼ばれ、前のコマンドで得られた stage1 std を使用します。
• stage2 コンパイラで librustdoc とその他多数のものをビルドします。

これを行う必要はほとんどありません。

特定のコンポーネントをビルドする

標準ライブラリで作業している場合、おそらく他のすべてのデフォルトコンポーネントをビルドする必要はありません。 代わりに、次のように名前を指定して特定のコンポーネントをビルドできます。

./x build --stage 1 library

x setup の実行時に library プロファイルを選択した場合は、--stage 1 を省略できます（これが デフォルトです）。

ツールをビルドしたい場合は、次を使用できます。

./x build src/tools/cargo

ツールのテストに関するセクションも確認できます。

rustup ツールチェーンを作成する

rustc のビルドに成功すると、build ディレクトリ内に多数のファイルが作成されます。 生成された rustc を実際に実行するには、rustup ツールチェーンを作成することを推奨します。 以下に示す最初のコマンドは、上記の手順でビルドされた stage1 ツールチェーンを stage1 という名前で作成します。 2 番目のコマンドは、stage1 コンパイラを使用して stage2 ツールチェーンを作成します。 これは将来、テストスイート全体を実行する場合に必要になりますが、 このページではビルドされません。 stage2 のビルドは stage1 の場合と同じ ./x build コマンドで行いますが、 代わりにステージが 2 であることを指定します。

rustup toolchain link stage1 build/host/stage1
rustup toolchain link stage2 build/host/stage2

これで、ビルドした rustc をツールチェーン経由で実行できます。 -vV を付けて実行すると、ローカル環境からのビルドであることを示す -dev で終わる バージョン番号が表示されるはずです。

$ rustc +stage1 -vV
rustc 1.48.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.48.0-dev
LLVM version: 11.0

rustup ツールチェーンは、build ディレクトリ内でコンパイルされた指定のツールチェーンを指すため、 そのツールチェーン/ステージに対して x build または x test が実行されるたびに、 rustup ツールチェーンも更新されます。

注意: ビルドしたツールチェーンには cargo が含まれていません。 この場合、rustup は インストール済みの nightly、beta、または stable ツールチェーンの cargo の使用にフォールバックします （この順序で）。 不安定な cargo フラグを使用する必要がある場合は、まだであれば必ず rustup install nightly を実行してください。 カスタムツールチェーンに関する rustup ドキュメントを参照してください。

注意: rust-analyzer と IntelliJ Rust プラグインは、proc macros を扱うために rust-analyzer-proc-macro-srv というコンポーネントを使用します。 プロジェクトでカスタムツールチェーンを使用するつもりがある場合 （例: rustup override set stage1 経由）、このコンポーネントを ビルドするとよいでしょう。

./x build proc-macro-srv-cli

クロスコンパイル用のターゲットをビルドする

他のターゲット向けにクロスコンパイルできるコンパイラを生成するには、 任意の数の target フラグを x build に渡します。 たとえば、ホストプラットフォームが x86_64-unknown-linux-gnu で、 クロスコンパイルターゲットが wasm32-wasip1 の場合は、次のようにビルドできます。

./x build --target x86_64-unknown-linux-gnu,wasm32-wasip1

生成されるコンパイラが proc macros やビルドスクリプトを含む crate をビルドできるようにしたい場合は、 ホストプラットフォーム（この場合は x86_64-unknown-linux-gnu）のターゲットサポートを 明示的にビルドする必要があることに注意してください。

x build にフラグを渡さずに常に他のターゲット向けにビルドしたい場合は、 次のように bootstrap.toml の [build] セクションで設定できます。

build.target = ["x86_64-unknown-linux-gnu", "wasm32-wasip1"]

一部のターゲット向けにビルドするには、外部依存関係がインストールされている必要がある点に注意してください （例: musl ターゲットをビルドするには、musl のローカルコピーが必要です）。 ターゲット固有の設定（例: musl のローカルコピーへのパス）は、 bootstrap.toml で指定する必要があります。 ターゲット固有の設定キーについては、bootstrap.example.toml を参照してください。

ターゲットをビルドするために必要な完全な設定例については、 rustc book にアクセスし、 左側の「Platform Support」見出しの下にある任意のターゲットを選択して、 そのターゲット用のコンパイラをビルドすることに関連するセクションを参照してください。 rustc book に対応するページがないターゲットについては、 Rust インフラストラクチャ自体がクロスコンパイルのセットアップと設定に使用している Dockerfile を調べる と役立つ場合があります。

rustup ツールチェーンを作成する前のセクションの手順に従っている場合、 コンパイラをビルドしたら、次のようにクロスコンパイルに使用できるようになります。

cargo +stage1 build --target wasm32-wasip1

その他の x コマンド

他にも便利な x コマンドがいくつかあります。 それらの一部については、他のセクションで詳しく説明します。

• ビルド関連:
  • ./x build – stage 1 コンパイラを使用してすべてをビルドします。 std までだけではありません
  • ./x build --stage 2 – rustdoc を含め、stage 2 コンパイラですべてをビルドします
• テストの実行（詳細については テストの実行に関するセクション を参照してください）:
  • ./x test library/std – std のユニットテストと統合テストを実行します
  • ./x test tests/ui – ui テストスイートを実行します
  • ./x test tests/ui/const-generics - ui テストスイートの const-generics/ サブディレクトリにあるすべてのテストを実行します
  • ./x test tests/ui/const-generics/const-types.rs - ui テストスイートの 単一のテスト const-types.rs を実行します

ビルドディレクトリのクリーンアップ

場合によっては最初からやり直す必要がありますが、通常はそうではありません。 これを実行する必要がある場合、bootstrap が正常に動作していない可能性が非常に高いため、 何が問題なのかについてバグを報告するべきです。 すべてをクリーンアップする必要がある場合は、1 つのコマンドを実行するだけで済みます！

./x clean

rm -rf build でも機能しますが、その場合は LLVM を再ビルドする必要があり、 高速なコンピューターでも長い時間がかかることがあります。

ディスク容量に関する注意

コンパイラをビルドするには（特に stage 1 を超える場合）、かなりの空きディスク 容量が必要になることがあり、およそ 100GB 程度になる可能性があります。 これは、rust-analyzer 用に別のビルドディレクトリ（例: build-rust-analyzer）がある場合に さらに大きくなります。これは、各ユーザーに 設定されたディスク クォータ がある dev-desktop で発生しやすいですが、ローカル開発にも当てはまります。 場合によっては、次のことが必要になることがあります。

• build/ ディレクトリを削除する。
• build-rust-analyzer/ ディレクトリを削除する（別の rust-analyzer ビルドディレクトリがある場合）。
• cargo-bisect-rustc を使用している場合は、不要なツールチェーンをアンインストールする。 インストールされているツールチェーンは rustup toolchain list で確認できます。

1. issue#1707 ↩