こんにちは、Habr！ Rust 1.34.0を発表した記事「The Rustリリースチーム」の翻訳を紹介します。
Rust開発チームは、Rustの新しいバージョン1.34.0のリリースをお知らせします。 Rustは、誰もが信頼できる効率的なソフトウェアを作成できるようにするプログラミング言語です。
Rustの以前のバージョンがrustupを使用してインストールされている場合、Rustをバージョン1.34.0にアップグレードするには、次の手順を実行するだけです。
$ rustup update stable
rustupをまだインストールしていない場合は、当社のWebサイトの対応するページからインストールできます。
安定バージョン1.34.0に含まれるもの
このリリースの主な改善点は、代替貨物登録のサポートです。 リリースにはサポートも含まれてい? ドキュメンテーションテストで、 #[attribute(...)]およびTryFrom安定化のいくつかの改善。 詳細については、重要な事項について読むか、詳細なリリースノートを参照してください。
代替cargo登録
バージョン1.0以前は、Rustにはパブリックレジストリcrates.ioがありました 。 Cargo.tomlを使用してクレートをcargo publish 、 Cargo.toml [dependencies]セクションでこれらのクレートを簡単に接続しCargo.toml 。
ただし、すべての人が crates.ioにクレートを公開するわけではありません。 クローズドソースプロジェクトをサポートする人々はcrates.ioを使用できず、代わりに依存関係でgitまたはpathを指定する必要がありました。 小さなプロジェクトにはこのようなものはありませんが、組織に多くのクローズドソースのクレートがある場合、バージョン管理サポートの利点を失います。これはcrates.ioで利用できます。
このリリースから、Cargoは代替レジストリをサポートする可能性があります。 これらのレジストリはcrates.ioと共存するため、crates.ioとレジストリに依存するプログラムを作成できます。 ただし、crates.ioクレートは外部レジストリに依存できません。
代替レジストリを使用するには、次の行を.cargo/config追加する必要があります。 このファイルは、ホームディレクトリ（ ~/.cargo/config ）またはパッケージディレクトリにあります。
[registries] my-registry = { index = "https://my-intranet:8080/git/index" }
代替レジストリから依存関係を追加するのは簡単です。 Cargo.tomlで依存関係を指定する場合、 registryキーを使用して、代替レジストリからクレートを受け取りたいことをCargoが認識できるようにします。
[dependencies] other-crate = { version = "1.0", registry = "my-registry" }
クレートの作成者として、別のレジストリにクレートを公開する場合、最初に行う必要があるのは、 cargo loginコマンドを使用して認証トークンを~/.cargo/credentials保存することです。
cargo login --registry=my-registry
次に、 --registryフラグを使用して、ラックを公開するレジストリを指定できます。
cargo publish --registry=my-registry
独自のレジストリを実行する方法については、 ドキュメントを参照してください 。
? ドキュメンテーションテストで
RFC 1937は、オペレータのサポートを追加することを提案していました? fn main() 、 #[test]関数およびドキュメンテーションテストでは、 Option<T>またはResult<T, E>を返すことができます。エラーがあるオプションは、 fn main()場合はゼロ以外の終了コード、テストの場合はテストのドロップ。
fn main()および#[test]サポートは長い間実装されてきました 。 ただし、ドキュメントテストのサポートは、 fn main()明示的に存在するテストに限定されていました。
このリリースで?完全なサポートが追加されてい? ドキュメンテーションテストで。 これで、ドキュメントテストでこれをテストできます。
ドキュメンテーションテストの下部で、使用するエラーの種類を指定する必要があります。
ユーザー属性でのカスタムトークンストリームのサポート
Rustの手続き型マクロは、使用するユーザー属性を定義できます。 これまで、これらの属性は、次の構文に従ってパスツリーとリテラルに制限されていました。
#[foo(bar)] #[foo = "bar"] #[foo = 0] #[foo(bar = true)] #[foo(bar, baz(quux, foo = "bar"))]
手続き型マクロとは異なり、これらの補助属性はデリミタ内のトークンの任意のストリームを受け入れることができなかったため、 #[range(0..10)]または#[bound(T: MyTrait)]記述できませんでした。 代わりに、手続き型マクロのラックは、 #[range("0..10")]などのこのような構文に文字列を使用しました。
このリリースでは、カスタム属性#[attr($tokens)] により、 $tokens内の任意のトークンを使用できるようになり、マクロに従って一致します。 手続き型マクロクレートの作成者である場合は、ユーザー属性の構文で行が使用されているかどうか、およびトークンのストリームで置き換えることができるかどうかを確認してください。
TryFromおよびTryInto
TryFromおよびTryIntoは、型変換エラーをサポートするために安定化されています。
たとえば、 from_be_bytesおよび関連する整数型のメソッドは配列を受け取りますが、データは多くの場合スライスを通して読み取られます。 スライスと配列間の手動変換は退屈です。 新しい特性を使用すると、これは.try_into()と同じ行で実行できます。
let num = u32::from_be_bytes(slice.try_into()?);
u8からu32など、失敗しない変換の場合、 Infallibleタイプが追加されます。 このため、 TryFrom From特性を実装するすべてに対して自動的に実装されます。 将来的には、 Infallible !エイリアスにしたいと考えています ! （決して） 。
unsafe fn pre_execでunsafe fn pre_exec支持して、 fn before_exec廃止されunsafe fn pre_exec
Unixライクシステムでは、 CommandExt::before_exec使用して、 exec呼び出される前に閉鎖をスケジュールできました。
この閉鎖は、分岐後の子プロセスのコンテキストで実行されました。 これは、ファイル記述子やメモリ領域などのリソースが重複する可能性があることを意味します。 つまり、異なるプロセスでCopyタイプの値のコピーを取得できますが、元の値は親に残ります。 これにより 、未定義の動作が発生し、重複がないことを示唆するライブラリが破損する可能性があります。
したがって、 before_exec関数はunsafeとマークする必要があります。 このリリースでは、 unsafe fn pre_execでunsafe fn pre_exec支持して、 fn before_exec非推奨としてマークしunsafe fn pre_exec 。 CommandExt::pre_exec呼び出す場合CommandExt::pre_exec無効な複製を作成することにより、クロージャーがライブラリの不変条件に違反しないことを確認する必要があります。 before_execと似たような状況にあるライブラリを提供している場合、陳腐化について考え、 unsafeでunsafe代替物を提供してください。
ライブラリの安定化
1.34.0では、8ビット（ AtomicU8 ）で始まり64ビットで終わる、安定したアトミック整数の符号付き型と符号なし型のセットが拡張されました。
NonZeroU8などのNonZeroU8符号なし整数は、 以前は安定化されていました。 これにより、 Option<NonZeroU8>はOption<NonZeroU8>と同じサイズにu8ます。 このリリースでNonZeroI8 、 NonZeroI8などの署名付きバージョンNonZeroI8安定化されています。
関数iter::from_fnおよびiter::successors安定しています。 最初の方法では、 FnMut() -> Option<T>からイテレーターを作成できます。 ベクターから要素を繰り返し取得するために、 from_fn(|| vec.pop())記述できるようにfrom_fn(|| vec.pop()) 。 一方、2番目の関数は新しい反復子を作成し、次の各要素は前の要素に基づいて計算されます。
さらに、次のAPIが安定化されました。
詳細については、 詳細なリリースノートを参照してください。