1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Rust 1.96.0rustup update stable でインストールでき、今後のリリース検証には beta/nightly チャネルで参加可能
  • 新しい core::range::Range* 型は Iterator の代わりに IntoIterator を実装し、Copy の実装が可能になっており、将来的には範囲構文の基本型になる予定
  • assert_matches!debug_assert_matches! は、パターン不一致時に値の Debug 表現も一緒に出力し、テスト失敗の診断を容易にする
  • WebAssembly ターゲットでは、--allow-undefined がデフォルトで渡されなくなり、未定義シンボル は import ではなくリンカーエラーになる
  • Cargo にはサードパーティレジストリ利用者向けの CVE-2026-5223CVE-2026-5222 の修正が含まれ、crates.io 利用者は影響を受けない

Rust 1.96.0 の主な変更点

  • アップデートとテストチャネル

    • 既存の Rust を rustup でインストールしているユーザーは、rustup update stableRust 1.96.0 を入手できる
    • rustup がない場合は、Rust Web サイトの rustup インストールページ から導入でき、1.96.0 の詳細リリースノート も公開されている
    • 今後のリリース検証に参加するには、rustup default beta または rustup default nightlybeta/nightly チャネル を利用でき、バグは Rust issue tracker に報告可能
  • 新しい Range*

    • 既存の Range と関連する core::ops 型は、多くのユーザーが Copy を期待していたが、自身で Iterator を実装しているため Copy は実装されていなかった
    • 同じ型に IteratorCopy を同時に実装する方式は、Clippy が指摘する footgun であるため避けられていた
    • RFC3550 は、Iterator の代わりに IntoIterator を実装する代替の範囲型を提案しており、この構造ではそれらの型が Copy も実装できる
    • 標準ライブラリでは core::range::Rangecore::range::RangeFromcore::range::RangeInclusive と関連 イテレータ が安定化された
    • 近い将来の Rust バージョンでは、core::ops から再エクスポートされる core::range::RangeFullcore::range::RangeTo、そして現在の範囲型の新しい配置先となる core::range::legacy::* も追加される予定
    • 0..1 のような 範囲構文 は現在レガシー型を生成するが、将来の edition では core::range 型に切り替わる予定
    • 今回の安定化により、startend を分離しなくてもスライスアクセサを Copy 型に保持できる
    • 例:
      use core::range::Range;
      
      #[derive(Clone, Copy)]
      pub struct Span(Range<usize>);
      
      impl Span {
          pub fn of(self, s: &str) -> &str {
              &s[self.0]
          }
      }
      
    • 新しい RangeInclusive はフィールドを公開しており、レガシー版のように消費済みイテレータ状態の露出を避ける必要がない
    • 新しい型では反復を開始する前にまず変換が必要なため、公開フィールドは問題にならない
    • ライブラリ作者は公開 API でレガシーと新しい範囲型の両方を受け取る impl RangeBounds の利用を検討すべき
    • 具体的な型が必要な場合は、将来のデフォルトになる 新しい範囲型 を優先することが推奨される
  • パターンマッチングアサーションマクロ

    • 新しいマクロ assert_matches!debug_assert_matches! は、値が指定パターンに一致するかを検査し、一致しなければその値の Debug 表現付きで panic する
    • この 2 つのマクロは本質的には assert!(matches!(..))debug_assert!(matches!(..)) と同じだが、失敗時に出力される値によって 診断しやすさ が向上する
    • 同名のマクロを提供する人気のサードパーティクレートと衝突する可能性があるため、標準プレリュードには追加されていない
    • 使用前に core または std から直接 import する必要がある
    • 例:
      use core::assert_matches;
      
      /// [Random Number](https://xkcd.com/221/)
      fn get_random_number() -> u32 {
          // chosen by a fair dice roll.
          // guaranteed to be random.
          4
      }
      
      fn main() {
          assert_matches!(get_random_number(), 1..=6);
      }
      
  • WebAssembly ターゲットの変更

    • WebAssembly ターゲットは、もはやリンカーに --allow-undefined を渡さない
    • リンク時の 未定義シンボル"env" モジュールの WebAssembly import に変換されず、リンカーエラーになる
    • リンク関連シンボルがすべて未定義ならモジュールはリンクされないため、バグをより早く発見でき、シンボル名などに起因する偶発的な問題も防げる
    • 未定義のリンク関連シンボルは通常、ビルド時のバグまたは設定ミスを示す
    • 既存の挙動が意図されたものである場合は、RUSTFLAGS=-Clink-arg=--allow-undefined で元に戻すか、ソースコードでシンボルを定義するブロックに #[link(wasm_import_module = "env")] を使える
    • この変更は 以前のブログ告知 の後、Rust 1.96 で適用された

安定化 API とセキュリティ修正

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rsの意見
  • assert_matches は欲しくなることが多く、そのたびに新しいクレートを追加するか自分で再実装するか悩んでいたので、標準ライブラリに入るのはうれしい

    • テストで括弧の組を何百個も消せるのが楽しみというのは変だろうか? いや、まったくそんなことはない
  • 範囲を Copy にしようとしている段階が気に入っている 範囲を複製しなければならず驚いたことがたまにあったし、12..34 は小さくてコピー可能なデータであるべきだという直感にもより合っている ただ、同じ名前の型がいくつもできると、VS Code が次に use 宣言を自動追加するときに間違った型を持ってきてしまわないか少し心配だ

    A Rust version in the near future will also add [...] core::range::legacy::* as the new home for the current ranges. Range syntax like 0..1 still produces the legacy types for now, but will be updated to core::range types in a future edition.
    Rust の エディションシステム はかなり良いアイデアに見える

    • 私の知る限り、import で曖昧さが生じた場合、VS Code のコードアクションはどれを使うか選ぶ ドロップダウン を開くはず
    • こういう型を普段から頻繁に import する必要はないのではないかと思う ほとんどのユーザーにとっては新しい型の利点は小さいので、従来の型をそのまま使い続ければよく、次のエディション境界で新しい型が自動的に使われるようになる 明示的に両方のバージョンをサポートしようとするライブラリ作者が主に型を import することになりそうだ
  • These new macros have not been added to the standard prelude, because they would collide with popular third-party crates that provide macros with the same name. Instead, they should be manually imported from core or std before use.
    これは少し奇妙に感じる 将来的に変える予定があるのだろうか? エコシステムが移行したあと、たとえば3年後くらいに 小さな整理 として変えたくなる種類のことに見える

    • こういう点では エディション が役に立つ 既存のプロジェクトを壊さずに prelude を変更できる