Rust 1.34 Release

Hallo Habr! Ich präsentiere Ihnen die Übersetzung des Artikels "The Rust Release Team" Announcing Rust 1.34.0 " .


Das Rust-Entwicklungsteam freut sich, die Veröffentlichung einer neuen Version von Rust, 1.34.0, bekannt zu geben. Rust ist eine Programmiersprache, mit der jeder zuverlässige und effiziente Software erstellen kann.


Wenn Sie eine frühere Version von Rust mit rustup installiert haben, müssen Sie nur Folgendes tun, um Rust auf Version 1.34.0 zu aktualisieren:


$ rustup update stable 

Wenn Sie rustup noch nicht installiert haben, können Sie es von der entsprechenden Seite unserer Website installieren .


Was ist in der stabilen Version 1.34.0 enthalten


Die wesentliche Verbesserung dieser Version ist die Unterstützung alternativer Frachtregister. Enthält die Version auch Unterstützung ? In Dokumentationstests einige Verbesserungen bei #[attribute(...)] und TryFrom Stabilisierung. Lesen Sie weiter über wichtige Dinge oder lesen Sie die detaillierten Versionshinweise, um weitere Informationen zu erhalten.


Alternative Frachtregister


Vor Version 1.0 hatte Rust eine öffentliche Registrierung, crates.io . Menschen haben Kisten mit cargo publish und diese Kisten im Abschnitt [dependencies] von Cargo.toml einfach verbunden.


Allerdings möchte nicht jeder seine Kisten auf crates.io veröffentlichen. Personen, die Closed-Source-Projekte unterstützen, konnten crates.io nicht verwenden. Stattdessen mussten sie in den Abhängigkeiten git oder path angeben. Für kleine Projekte gibt es nichts Vergleichbares. Wenn Ihre Organisation jedoch über viele Closed-Source-Kisten verfügt, verlieren Sie die Vorteile der Versionsunterstützung, die in crates.io verfügbar ist.


Ab dieser Version unterstützt Cargo möglicherweise alternative Registrierungen. Diese Registrierungen existieren gleichzeitig mit crates.io, sodass Sie Programme schreiben können, die von crates.io und Ihrer Registrierung abhängen. Die crates.io-Baugruppenträger können jedoch nicht von einer externen Registrierung abhängen.


Um alternative Registrierungen zu verwenden, müssen Sie .cargo/config die folgenden Zeilen .cargo/config . Diese Datei kann sich in Ihrem Home-Verzeichnis ( ~/.cargo/config ) oder im Paketverzeichnis befinden.


 [registries] my-registry = { index = "https://my-intranet:8080/git/index" } 

Das Hinzufügen einer Abhängigkeit von einer alternativen Registrierung ist einfach. Wenn Sie die Abhängigkeit in Cargo.toml , verwenden Sie den registry damit Cargo weiß, dass Sie die Kiste von der alternativen Registrierung erhalten möchten:


 [dependencies] other-crate = { version = "1.0", registry = "my-registry" } 

Wenn Sie als Autor der Kiste Ihre Kiste in einer alternativen Registrierung veröffentlichen möchten, müssen Sie zunächst das Authentifizierungstoken in ~/.cargo/credentials mit dem Befehl für die cargo login ~/.cargo/credentials :


 cargo login --registry=my-registry 

Als Nächstes können Sie mit dem Flag --registry die Registrierung angeben, in der das Rack veröffentlicht wird:


 cargo publish --registry=my-registry 

Informationen dazu, wie Sie Ihre eigene Registrierung ausführen können, finden Sie in der Dokumentation .


? in Dokumentationstests


Schlug RFC 1937 vor, Betreiberunterstützung hinzuzufügen ? in fn main() , #[test] -Funktionen und Dokumentationstests, sodass sie Option<T> oder Result<T, E> wobei die Option mit einem Fehler im Fall von fn main() einem Beendigungscode ungleich Null oder im Fall von Tests zu einem abgebrochenen Test führt .


Die Unterstützung in fn main() und #[test] seit langem implementiert. Die Unterstützung bei Dokumentationstests beschränkte sich jedoch auf Tests, bei denen fn main() explizit vorhanden war.


? in dieser Version volle Unterstützung hinzugefügt ? in Dokumentationstests. Jetzt können Sie in Ihren Dokumentationstests Folgendes schreiben:


 /// ```rust /// use std::io; /// let mut input = String::new(); /// io::stdin().read_line(&mut input)?; /// # Ok::<(), io:Error>(()) /// ``` fn my_func() {} 

Am Ende des Dokumentationstests müssen Sie noch die Art des Fehlers angeben, der verwendet werden soll.


Unterstützung für benutzerdefinierten Token-Stream in Benutzerattributen


Prozedurale Makros in Rust können die von ihnen verwendeten Benutzerattribute definieren. Bisher waren diese Attribute auf Pfadbäume und Literale gemäß der folgenden Syntax beschränkt:


 #[foo(bar)] #[foo = "bar"] #[foo = 0] #[foo(bar = true)] #[foo(bar, baz(quux, foo = "bar"))] 

Im Gegensatz zu prozeduralen Makros konnten diese #[range(0..10)] keinen beliebigen Strom von Token im Trennzeichen akzeptieren, weshalb Sie nicht #[range(0..10)] oder #[bound(T: MyTrait)] . Racks mit prozeduralen Makros verwendeten stattdessen Zeichenfolgen für eine #[range("0..10")] Syntax, z. B. #[range("0..10")] .


In dieser Version ermöglichen die benutzerdefinierten Attribute #[attr($tokens)] die Verwendung beliebiger Token in $tokens , die gemäß den Makros übereinstimmen. Wenn Sie der Autor einer prozeduralen Makrokiste sind, überprüfen Sie bitte, ob die Zeichenfolgen in der Syntax Ihrer Benutzerattribute verwendet werden und ob sie durch einen Stream von Token ersetzt werden können.


TryFrom und TryInto


Die TryInto TryFrom und TryInto wurden stabilisiert, um Typkonvertierungsfehler zu unterstützen.


Beispielsweise erhalten from_be_bytes und verwandte Methoden von Ganzzahltypen ein Array, aber Daten werden häufig durch Slices gelesen. Die manuelle Konvertierung zwischen Slices und Arrays ist mühsam. Mit neuen Merkmalen kann dies in derselben Zeile wie .try_into() .


 let num = u32::from_be_bytes(slice.try_into()?); 

Für Konvertierungen, die nicht fehlschlagen können, z. B. u8 bis u32 , wird der Typ Infallible hinzugefügt. Aus diesem TryFrom automatisch für alles implementiert, was das From Merkmal implementiert. Wir hoffen, Infallible Zukunft zu Infallible Alias ​​für diesen ! (niemals) .


fn before_exec zugunsten von unsafe fn pre_exec


Auf Unix-ähnlichen Systemen konnten Sie mit der CommandExt::before_exec einen Abschluss planen, bevor exec aufgerufen wurde.


Dieser Verschluss wurde im Rahmen des untergeordneten Prozesses nach der Gabelung durchgeführt. Dies bedeutet, dass Ressourcen wie Dateideskriptoren und Speicherbereiche dupliziert werden können. Mit anderen Worten, Sie könnten in verschiedenen Prozessen eine Kopie eines Wertes vom Typ "Nicht Copy , während das Original im übergeordneten Element verbleibt. Dies kann zu undefiniertem Verhalten führen und Bibliotheken beschädigen, die auf das Fehlen von Duplikaten hinweisen .


Daher muss die Funktion before_exec als unsafe markiert werden. In dieser Version haben wir fn before_exec veraltet zugunsten von unsafe fn pre_exec . Wenn Sie CommandExt::pre_exec Sie sicherstellen, dass der Abschluss die Bibliotheksinvarianten nicht verletzt, indem Sie ungültige Duplikate erstellen. Wenn Sie eine Bibliothek before_exec , die sich before_exec in einer ähnlichen Situation before_exec , denken Sie an Veralterung und bieten Sie eine Alternative mit unsafe .


Bibliotheksstabilisierung


In 1.34.0 wurde der Satz stabiler atomarer Integer-Typen mit und ohne Vorzeichen erweitert, beginnend mit 8 Bit ( AtomicU8 ) und endend mit 64 Bit.


NonZeroU8 vorzeichenlose Ganzzahlen NonZeroU8 wie NonZeroU8 wurden zuvor stabilisiert. Dank dessen hat Option<NonZeroU8> die gleiche Größe wie u8 . Signierte Versionen wie NonZeroI8 in dieser Version stabilisiert.


Die Funktionen iter::from_fn und iter::successors stabilisiert. Mit dem ersten können Sie einen Iterator aus FnMut() -> Option<T> erstellen. Um Elemente iterativ aus einem Vektor abzurufen, können Sie jetzt from_fn(|| vec.pop()) schreiben. In der Zwischenzeit erstellt die zweite Funktion einen neuen Iterator, in dem jedes nächste Element basierend auf dem vorherigen berechnet wird.


Zusätzlich wurden die folgenden APIs stabilisiert:



Weitere Informationen finden Sie in den detaillierten Versionshinweisen.

Source: https://habr.com/ru/post/de448366/


All Articles