GCCベースのRustコンパイラ開発の進展

 (lwn.net)
2 ポイント 投稿者 GN⁺ 2023-12-19 | 1件のコメント | WhatsAppで共有

GCCベースのRustコンパイラ開発の進捗状況

  • GCCベースのRustコンパイラプロジェクトであるgccrsは2014年に開始され、GNU Compiler Collection（GCC）内でRustコンパイラを実装することを目標としている。
  • gccrsの目標はGCC 13リリースに含まれることだったが、これは達成されず、現在はGCC 14（2024年半ばのリリース予定）に含まれることを目標としている。
  • gccrsはRustバージョン1.49を対象としており、これはconst genericsが導入される前の最後のバージョンである。
  • gccrsプロジェクトの重要な原則の1つは、Rustの「superset」を作らず、rustcの出力をそのまま再現することである。
  • Rust標準ライブラリは複数の「crates」で構成されており、gccrsはその中でもcoreおよびalloc crateのコンパイルをサポートすることに注力している。
  • gccrsは現在、複数の機能不足によりこれらのcratesをコンパイルできず、borrow checkerの不在と、GCCでサポートされていないLLVM intrinsicsの不足が問題となっている。

GCCエコシステムの利点の活用

  • gccrs開発の主な理由の1つは、GCCのセキュリティプラグインを活用できるようにすることにある。
  • gccrsはすでにSega Dreamcastホームブリューコミュニティで使用されており、GCCプラグインを使ってunsafe Rustコードの静的解析を行うことができる。
  • gccrsの取り組みを通じてRust仕様に追加機能を貢献できており、Rustの公式仕様策定作業にも参加したいとしている。

開発中の機能

  • gccrsには依然として多くの中核機能が欠けており、async/await、GCCに存在しないLLVM intrinsics、format_args!()マクロなどが含まれる。
  • Poloniusプロジェクトは、rustcの現在のborrow checkerの欠点を解決するため、別のアルゴリズムで参照のライフタイムを計算するborrow checkerを実装している。
  • format_args!()マクロの作業が開始されており、これは他の文字列フォーマットマクロに渡される引数を構成するために必要である。

rustc_codegen_gcc

  • rustc_codegen_gccは、gccrsよりも成熟しており、スコープが限定された別のGCCベースのRustプロジェクトである。
  • rustc_codegen_gccはlibgccjitライブラリを使用してrustcのLLVMバックエンドAPIに接続し、rustcとGCCの後段でコンパイルを実行する。
  • 2023年10月時点でrustc_codegen_gccは、追加パッチなしでRust for Linuxをコンパイルできる。

Rust for Linux

  • Rust for Linuxプロジェクトは、rustcまたはrustc_codegen_gccを使ってカーネル向けRustコードをビルドする方法に関するドキュメントを提供している。
  • gccrsはRust for Linux対応を目標としているが、現在サポートされているrustcバージョンとの大きな差異により、実現はまだ遠いように見える。

GN⁺の意見

  • gccrsプロジェクトはRust言語のGCCベースのコンパイラ実装を目指しており、これはRustエコシステムに多様性をもたらし、GCCのセキュリティプラグインのような既存ツールを活用できる可能性を持っている。
  • gccrsがRust標準ライブラリの中核部分をまだコンパイルできない状況にある一方で、すでにSega Dreamcastホームブリューコミュニティで実際の利用例が見られる点は注目に値する。
  • この記事は、Rust言語の多様なコンパイラ実装と、それに伴うエコシステム拡張の可能性について興味深い洞察を提供している。

関連記事

1件のコメント

 
GN⁺ 2023-12-19
Hacker News の意見

  • 1つ目のコメント要約:

    • 記事では gccrs の開発動機に関する主張が弱いと感じる。
    • gccrs は GCC のセキュリティプラグインを活用するために開発されている。
    • Linux カーネルに Rust サポートを追加する "Rust for Linux" イニシアチブも、もう1つの理由である。
    • Linux カーネルを GNU ツールチェーンだけでコンパイルしたいカーネル開発者が多く、重要な動機になっている。
    • GCC をバックエンドとして使う理由は説明されているが、なぜ重複したフロントエンドが必要なのかについての説明は不足している。
    • C++ の失敗から学ぶべきであり、多様なフロントエンドはプラットフォーム間の開発を難しくする。
    • gccrs が "GNU Rust" にならないよう注意を払っており、rustc の出力を再現しようとしている。

  • 2つ目のコメント要約:

    • Rust には言語標準が必要である。
    • 多くの組織や業界は、標準がなければ Rust を採用しないだろう。
    • C、C++、C#、JavaScript（ECMAScript）のような他の言語はすべて標準を持っている。

  • 3つ目のコメント要約:

    • GCC-RS に対する否定的な反応に驚いた。
    • 言語が複数の実装を持っていないなら、その言語は不完全である。

  • 4つ目のコメント要約:

    • gccrs によって LLVM がサポートしていないアーキテクチャ向けの Rust サポートが可能になるだろう。

  • 5つ目のコメント要約:

    • gccrs が rustc のバグや癖まで再現しようとするのは誤りだと思う。
    • Rust には公式な仕様がなく、単一の参照実装だけで文書化するのは長期的な弱点である。
    • 既存コードがすべての実装で動作するようにしようとするのは合理的だが、誤った判断やバグを恒久化する問題がある。
    • Microsoft は古いプログラムが動き続けるように多大な努力を払っている。
    • Rust は言語開発の初期段階でこうした負担を負うべきではない。
    • 言語が進化するには QA と QC を受け入れる必要がある。
    • 強力な標準を持つ言語は、この考え方を受け入れている。

  • 6つ目のコメント要約:

    • lwn.net のリンクを投稿してくれたおかげで、購読更新を思い出せたことに感謝する。

  • 7つ目のコメント要約:

    • Linux はすでに clang を使ってコンパイルできる。
    • GNU の「純粋性」のために、こうした重複した取り組みを開発・維持する価値はないように見える。