Rust 1.13リリース

Rustチームは、Rust 1.13.0のリリースをお知らせします。 Rustは、セキュリティ、速度、および並列コード実行を目的としたシステムプログラミング言語です。







いつものように、公式Webサイトの対応するページからRust 1.13.0をインストールできます。 また 、GitHubの1.13.0での変更の詳細なリストに精通しています。 このリリースには、1,448個のパッチが含まれています。







Rustでは本当に暑い時期でした。 RustConf 、 RustFest 、 Rust Belt Rustの 3つの連続した会議に参加しました。 多くのRust愛好家に会えてよかったです。 初めて多くの人に会いました! 私たちは将来について多くのことを考え、 2017年の計画を立て 、ユーザーが必要と するツールを作成しました 。







それにも関わらず、クールな新機能を備えた新しいリリースを作成しました。







安定バージョン1.13に含まれるもの



リリース1.13には待望の演算子が含まれています?



、コンパイルの加速、追加

Cargoおよび標準ライブラリの一部の機能。 このリリースでは、ドキュメントとエラーメッセージに多くの小さな改善が加えられています。 これは多くの人々の作業の結果であり、リリースノートには個別に記載されていません。







このリリースには、Cargoの重要な脆弱性の修正が含まれています。 curlとOpenSSLに依存しますが、

そして、両方とも最近セキュリティアップデートを投稿しました。 詳細については、 curl 7.51.0およびOpenSSL 1.0.2jの対応する発表を参照してください。







演算子?





Rustは新しい演算子を取得しました?



。 バグの処理がより良くなり、

視覚的なノイズを除去します。 たとえば、ファイルからデータを読み取るコードがあります。







 fn read_username_from_file() -> Result<String, io::Error> { let f = File::open("username.txt"); let mut f = match f { Ok(file) => file, Err(e) => return Err(e), }; let mut s = String::new(); match f.read_to_string(&mut s) { Ok(_) => Ok(s), Err(e) => Err(e), } }
      
      





コードには、エラーを引き起こす可能性のある2つのパスが含まれています。ファイルを開くことと、そこからデータを読み取ることです。 それらの1つがクラッシュした場合、 read_username_from_file



関数からエラーを返す必要があります。 これを行うには、I / O操作の結果をmatch



必要があります。 ただし、ここでは単純にエラーを呼び出しスタックにスローし、 match



を使用することは定型的なコードの繰り返しです。 読みにくい。







C 上記のコードは次のようになります。







 fn read_username_from_file() -> Result<String, io::Error> { let mut f = File::open("username.txt")?; let mut s = String::new(); f.read_to_string(&mut s)?; Ok(s) }
      
      





?



は、上で書いたmatch



表現全体の省略形です。 つまり?



Result



を取り、それがOk



場合、それを展開し、埋め込まれた値を返します。 Result



値がErr



?



現在の関数から制御を返します。 読みやすくなっています。式全体ではなく、記号「?」を使用しています。 そのため、標準的な方法でエラーを処理し、スタックに渡すことを示します。







経験豊富なRustプログラマーは、これがtry!



マクロと同じであることに気付くかもしれませtry!



、

Rust 1.0



以降で使用可能です。 実際、これは同じです。 1.13より前では、 read_username_from_file



は次のように実装できました。







 fn read_username_from_file() -> Result<String, io::Error> { let mut f = try!(File::open("username.txt")); let mut s = String::new(); try!(f.read_to_string(&mut s)); Ok(s) }
      
      





それでは、マクロが既にあるのに、なぜ言語に拡張子を追加するのでしょうか? さまざまな理由で。

はじめてtry!



その例外的な有用性を再確認し、慣用的なRustでよく使用されます。 頻繁に使用されるため、甘い構文に値します。 この種の進化は、強力なマクロシステムの大きな利点の1つです。言語自体を変更せずに、提案された言語構文拡張をプロトタイプ化し、テストできます。 また、非常に有用になったマクロは、言語機能の欠如を示している場合があります。 try!



からのそのような進化try!



で?



これの良い例です。







try!



糖衣が必要です-これは、チェーン内で複数の呼び出しが行われた場合にかなりいものです。 比較する:







 try!(try!(try!(foo()).bar()).baz())
      
      





とは対照的に:







 foo()?.bar()?.baz()?
      
      





最初のフラグメントは非常に読みにくく、各エラー処理レイヤーの属性

式呼び出しの先頭へtry!



。 これには、エラーの些細な転送に注意を集中させる必要があり、メインの動作コードfoo



、 bar



、およびbaz



呼び出します。 エラー処理を伴うこのタイプのコールフックは、 builder



デザインパターンのような状況で一般的です。







最後に、特殊な構文はエラー出力を容易にします-使用法を説明できます?



。 また、マクロからのコードの場合、適切なミスを犯すことは困難です。 ただし、このリリースでは、使用エラーメッセージは?



まだ完全には実装されていません。







これはわずかな改善ですが、私たちの経験では?



-人間工学の価値ある改善をtry!



。 これは、Rustが受け続ける生活の質の一貫した改善の良い例です。







さらに詳しく RFC 243を参照してください。







パフォーマンスの改善



コンパイラのパフォーマンスに真剣に取り組んでいます。 すでにいくつかの良いニュースがありますが、将来のリリースではさらに良くなります。







Mark SimulacrumとNick Cameronは、コンパイラーのパフォーマンス追跡ツールであるperf.rust-lang.orgを磨きました 。 彼は定期的に専用ハードウェアでrustc-benchmarksを実行し、時間の経過とともに変更を追跡します。 このツールは、各コンパイル手順の結果を記録し、パフォーマンスの低下につながるコミットの検索範囲を絞り込むために開発者が使用します。 これはツールキットの重要な部分です!







これを使用して、1.13開発期間(8月16日から9月29日まで)のパフォーマンスグラフを見ることができます(グラフを以下に示します)。 スケジュールは8月25日に開始され、信頼性の低い、不完全な、または矛盾する結果を除外するために、いくつかの基準に従ってフィルタリングされます。 対応する統計ページで定量化された大幅な削減に気付くことができます。









性能グラフ









9月1日、大幅な改善がありました-ニコは、 変換中に正規化されたキャッシュ予測をオンにしました。 これは、LLVM IR生成中に、コンパイラーが使用される各場所で関連タイプの特定のインスタンスを再カウントしなくなることを意味します。 現在では、以前に計算された値を再利用します。 この最適化はコードには影響しませんが、特定の典型的なフラグメントに遭遇すると、違いに気付くでしょう。 たとえば、 futures-rsの場合、デバッグバージョンのビルド時間は40%向上しました 。







別の同様の最適化がMichael Woeristerによって実装されています。 多くのインライン関数をエクスポートするコンテナーのコンパイルを高速化します。 関数が#[inline]



としてマークされている場合、コンパイラは、現在のコンテナで使用するための通常の変換に加えて、その表現をMIRでrlibに保存します。 次に、この関数を呼び出す各コンテナーで翻訳します。 振り返ってみると、Michaelは明白な最適化を行いました。場合によっては、インライン関数は他のコンテナー専用であるため、コンパイラーは宣言されたコンテナーでそれらを変換する必要はありません。 もちろん、そこで呼び出される場合を除きます。 これにより、関数をLLVM IRに変換し、LLVMを処理する時間を節約できます:最適化とコード生成。







場合によっては、これにより印象的な結果が得られます。 Ndarrayのビルド時間は50%向上し 、(未公開の) winapi 0.3では、rustcはネイティブコードをまったく生成しなくなりました。







しかし、待ってください、それだけではありません! Nick Nethercote は、プロファイリングとマイクロ最適化に焦点を合わせて、 コンパイラーのパフォーマンスにも注意を向けました 。 このリリースにはすでに彼の労働の成果のいくつかが含まれており 、その他は1.14に予定されています。







詳細については、 リリースノートを参照してください。







その他の注目すべき変更



このリリースには、Cargoの重要な脆弱性の修正が含まれています。 curlとOpenSSLに依存しており、どちらも最近セキュリティアップデートを投稿しました。 詳細については、 curl 7.51.0およびOpenSSL 1.0.2jの対応する発表を参照してください。







タイプ( RFC 873 )の代わりにマクロを使用し、ステートメントに属性を適用できるようになりました( RFC 16 ):







 //  ,    macro_rules! Tuple { { $A:ty,$B:ty } => { ($A, $B) } } let x: Tuple!(i32, i32) = (1, 2);
      
      





 //        #[allow(uppercase_variable)] let BAD_STYLE = List::new();
      
      





組み込みのリセットフラグ( 英語のインラインドロップフラグ)は削除されました。 以前、コンパイラは、構造体がいくつかの実行パスで移動したときにデストラクタを実行するかどうかを理解するために、構造体に「リセットフラグ」を保存していました。 これにより、構造体のサイズが大きくなり、FFI境界を越えてデストラクタを持つ型の転送ができなくなりました。 実行パスに関してのみ構造を移動しないコードの場合、このメモリは無駄になりました。 1.12では、MIRがデフォルトのトランスレーターになりました-これは、 これらの組み込みリセットフラグの削除を含む、多くの改善の基盤でした。 現在、リセットフラグはそれらを必要とする関数のスタック上にあります。







1.13では、浮動小数点数のハードウェア実装によるARMのコード生成に重大なバグがあります。 これらはほとんどのARMベースのプラットフォームです。 ARMは現在サポートレベル2プラットフォームであるため、このバグはリリースをブロックしません。 1.13にはセキュリティパッチが含まれているため、ARMユーザーは1.14ベータ版を使用することをお勧めします。 このスレッドは、この問題の修正をすぐに受け取ります。







言語機会の安定化





ライブラリの安定化





貨物の特徴





詳細については、 リリースノートを参照してください。







開発者バージョン1.13.0



155人が1.13.0に貢献しました。 どうもありがとう!







参加者リスト
  • アーロン・ギャラガー
  • アビシェーク・クマール
  • 宣言
  • アダム・メジスキ
  • アーメド・チャールズ
  • アレクセイ・クラドフ
  • アレクサンダー・フォン・グルックIV
  • アレクサンドル・オリベイラ
  • アレックスブルカ
  • アレックス・クリトン
  • アマニユー・ダントラス
  • アミット・レヴィ
  • アンドレア・コラディ
  • アンドレ・ボーガス
  • アンドリュー・カン
  • アンドリュー・カンティーノ
  • アンドリュー・ライギン
  • アンドリュー・パセルティナー
  • アンディ・ラッセル
  • アリエル・ベン・イェフダ
  • アーサー
  • アシュリー・ウィリアムズ
  • アチュラパダン
  • オースティンヒックス
  • ボール
  • ブライアン・アンダーソン
  • c4rlo
  • カレブ・ジョーンズ
  • 検閲されたユーザー名
  • cgswords
  • changchun.fan
  • チウ・シアン・ス
  • クリス・スタンクス
  • クリストファー・セア
  • クリス・ウォン
  • クレメントミャオ
  • クーブランド
  • コリー・ファーウェル
  • クリスティ・コブザレンコ
  • 暗号宇宙
  • 唐城
  • ダニエル・バラッキ
  • DarkEld3r
  • デビッド・トルネー
  • ダスティン・ベンシング
  • エデュアルド・ブルテスク
  • エドゥアルド・ミハイ・ブルテスク
  • エイタン・アドラー
  • エリック・ウッゲルダール
  • エステバン・キューバー
  • ユージンバリン
  • ユージン・R・ゴンザレス
  • ファビアン・ザイザー
  • フェデリコ・ラバシオ
  • フェリックス・S・クロックII
  • フロリアン・ギルチャー
  • ギャビンパン
  • ゲオルグ・ブランドル
  • ゴメス
  • ジャンニ・シッカレッリ
  • ギョーム・ゴメス
  • ジェイコブ
  • ヤコブパドキンス
  • ジェイク・ゴールズボロ
  • ジェイク・ゴールディング
  • ヤコブ・デムラー
  • ジェームズ・デュリー
  • ジェームズ・ミラー
  • ジャレッド・ローシュ
  • ジャレッド・ワイルズ
  • ジェフリー・セイフリード
  • ジェスラダー
  • ジョー・ニーマン
  • ヨハネス・レスバーグ
  • ジョン・ファイヤーボー
  • ジョンターゲン
  • ジョナス・シエヴィンク
  • ジョナサン・ターナー
  • ホルヘ・アパリシオ
  • ジョセフ・ダン
  • ジョシュ・トリプレット
  • ジャスティン・ルフェーブル
  • キーガン・マカリスター
  • キース・ヨン
  • クンホン・リー
  • king6cong
  • 騎士
  • knight42
  • カイロ・ギンズバーグ
  • リゴ
  • マニッシュゴレガオカル
  • マークシミュレーション
  • マシュー・ピジアック
  • マット・クシュタット
  • マカートン
  • マイケル・レイン
  • マイケル・ウーリスター
  • ミハイル・モディン
  • モヒト・アガルワル
  • ナズム・カン・アルティバ
  • ニール・ウィリアムズ
  • ニコラス・ネザーコート
  • ニック・キャメロン
  • ニック・プラット
  • ニールズ・サシャ・リーダイク
  • ニキータ・バクサリヤール
  • ニコ・マタキス
  • オリバー・ミドルトン
  • オリバー・シュナイダー
  • オルベア
  • パナシェ・M・ファンディラ
  • パトリック・ウォルトン
  • ポール・ファネッリ
  • フィリップ
  • フィル・ラフウィンド
  • ピョートル・ジョーニャック
  • プリニカー
  • クィートミスドリーブス
  • ラフル・シャルマ
  • リチャード・ジャニス・ゴールドシュミット
  • スコット・ア・カー
  • スコット・オルソン
  • ショーン・マクター
  • セバスチャン・ウルリッチ
  • セバスチャン・マリー
  • ソ・サンヒョン
  • セルジオ・ベニテス
  • シャムスンダB
  • シレヌス
  • シモナス・カズラウスカス
  • サイモン・サパン
  • スリニバス・レディ・サティパルティ
  • ステファン・シンドラー
  • ステファン・ヒューゲル
  • スティーブ・クラブニック
  • スティーブンアレン
  • スティーブン・ファクラー
  • テリー・サン
  • トーマス・ガルシア
  • ティム・ノイマン
  • トビアス・ブッチャー
  • トマス・ミエスコ
  • trixnz
  • シェパンレコンホーベ
  • ウルリッヒウェイガンド
  • ウルリック・スヴェルドラップ
  • ヴァディム・チュグノフ
  • ヴァディム・ペトロチェンコフ
  • ヴァンジャ・コスミック
  • ヴィンセントエスケープ
  • ウェズリー・ワイザー
  • ウィリアム・リー
  • シミン・ルオ
  • ヨッシ・コンスタンティノフスキー
  • ジマレ



All Articles