Bonjour, Habr! Je vous présente la traduction de l'article "The Rust Release Team" Announcing Rust 1.34.0 " .
L'équipe de développement de Rust est heureuse d'annoncer la sortie d'une nouvelle version de Rust, 1.34.0. Rust est un langage de programmation qui permet à chacun de créer des logiciels fiables et efficaces.
Si vous avez une version précédente de Rust installée à l'aide de rustup, alors pour mettre à niveau Rust vers la version 1.34.0, il vous suffit de faire:
$ rustup update stable
Si vous n'avez pas encore installé rustup, vous pouvez l' installer à partir de la page correspondante de notre site Web.
Ce qui est inclus dans la version stable 1.34.0
L'amélioration majeure de cette version est la prise en charge de registres de fret alternatifs. La version inclut-elle également un support ? dans les tests de documentation, quelques améliorations dans la stabilisation #[attribute(...)] et TryFrom . Lisez la suite sur les éléments clés ou consultez les notes de version détaillées pour plus d'informations.
Registres de cargo alternatifs
Avant la version 1.0, Rust avait un registre public, crates.io . Les gens ont publié des caisses en utilisant cargo publish et ont facilement connecté ces caisses dans la section [dependencies] de Cargo.toml .
Cependant, tout le monde ne veut pas publier ses caisses sur crates.io. Les personnes prenant en charge des projets de sources fermées ne pouvaient pas utiliser crates.io, et à la place, elles devaient spécifier git ou path dans les dépendances. Il n'y a rien de tel pour les petits projets, mais si votre organisation a beaucoup de caisses fermées, vous perdez les avantages de la prise en charge de la gestion des versions, qui est disponible dans crates.io.
À partir de cette version, Cargo peut prendre en charge d'autres registres. Ces registres coexistent avec crates.io, vous pouvez donc écrire des programmes qui dépendent de crates.io et de votre registre. Cependant, les bacs à cartes crates.io ne peuvent pas dépendre d'un registre externe.
Pour utiliser des registres alternatifs, vous devez ajouter les lignes suivantes à .cargo/config . Ce fichier peut être dans votre répertoire personnel ( ~/.cargo/config ) ou dans le répertoire du package.
[registries] my-registry = { index = "https://my-intranet:8080/git/index" }
Ajouter une dépendance à partir d'un registre alternatif est facile. Lorsque vous spécifiez la dépendance dans Cargo.toml , utilisez la clé de registry pour que Cargo sache que vous souhaitez recevoir la caisse du registre alternatif:
[dependencies] other-crate = { version = "1.0", registry = "my-registry" }
En tant qu'auteur de la caisse, si vous souhaitez publier votre caisse dans un autre registre, la première chose que vous devez faire est d'enregistrer le jeton d'authentification dans ~/.cargo/credentials à l'aide de la commande de cargo login :
cargo login --registry=my-registry
Ensuite, vous pouvez utiliser l'indicateur --registry pour spécifier le registre dans lequel le rack sera publié:
cargo publish --registry=my-registry
Sur la façon dont vous pouvez exécuter votre propre registre, vous pouvez le trouver dans la documentation .
? dans les tests de documentation
La RFC 1937 proposait-elle d'ajouter un support opérateur ? dans fn main() , #[test] fonctions et tests de documentation, leur permettant de retourner Option<T> ou Result<T, E> où l'option avec une erreur donne un code de terminaison différent de zéro dans le cas de fn main() ou un test abandonné dans le cas des tests .
Le support dans fn main() et #[test] implémenté depuis longtemps . Cependant, la prise en charge des tests de documentation était limitée aux tests dans lesquels fn main() explicitement présent.
? support complet ? ajouté dans cette version ? dans les tests de documentation. Vous pouvez maintenant écrire dans vos tests de documentation ceci:
Au bas du test de documentation, vous devez toujours indiquer le type d'erreur qui sera utilisé.
Prise en charge du flux de jetons personnalisé dans les attributs utilisateur
Les macros procédurales dans Rust peuvent définir les attributs utilisateur qu'elles utilisent. Jusqu'à présent, ces attributs étaient limités aux arbres de chemin et aux littéraux selon la syntaxe suivante:
#[foo(bar)] #[foo = "bar"] #[foo = 0] #[foo(bar = true)] #[foo(bar, baz(quux, foo = "bar"))]
Contrairement aux macros procédurales, ces attributs auxiliaires ne pouvaient pas accepter un flux arbitraire de jetons dans le délimiteur, c'est pourquoi vous ne pouviez pas écrire #[range(0..10)] ou #[bound(T: MyTrait)] . Les racks de macros procédurales utilisaient à la place des chaînes pour une syntaxe comme celle-ci, par exemple #[range("0..10")] .
Avec cette version, les attributs personnalisés #[attr($tokens)] permettent d'utiliser des jetons arbitraires dans $tokens , en les faisant correspondre en fonction des macros. Si vous êtes l'auteur d'une caisse de macros procédurale, veuillez vérifier si les chaînes sont utilisées dans la syntaxe de vos attributs utilisateur et si elles peuvent être remplacées par un flux de jetons.
TryFrom et TryInto
Les TryInto TryFrom et TryInto ont été stabilisés pour prendre en charge les erreurs de conversion de type.
Par exemple, from_be_bytes et les méthodes associées de types entiers reçoivent un tableau, mais les données sont souvent lues via des tranches. La conversion manuelle entre les tranches et les tableaux est fastidieuse. Avec de nouveaux traits, cela peut être fait sur la même ligne que .try_into() .
let num = u32::from_be_bytes(slice.try_into()?);
Pour les conversions qui ne peuvent pas échouer, telles que u8 en u32 , le type Infallible est ajouté. Pour cette raison, TryFrom automatiquement implémenté pour tout ce qui implémente la caractéristique From . À l'avenir, nous espérons faire d' Infallible alias pour le ! (jamais) .
fn before_exec déconseillé au profit de unsafe fn pre_exec
Sur les systèmes de type Unix, la fonction CommandExt::before_exec vous a permis de planifier une fermeture avant l' exec .
Cette fermeture a été réalisée dans le cadre du processus enfant après le fork. Cela signifie que les ressources, telles que les descripteurs de fichiers et les zones de mémoire, peuvent être dupliquées. En d'autres termes, vous pouvez obtenir une copie d'une valeur de type non Copy dans différents processus, tandis que l'original reste dans le parent. Cela pourrait conduire à un comportement indéfini et casser des bibliothèques qui suggèrent l'absence de duplication .
Par conséquent, la fonction before_exec doit être marquée comme unsafe . Dans cette version, nous avons marqué fn before_exec déconseillé au profit de unsafe fn pre_exec . Lorsque vous appelez CommandExt::pre_exec vous devez vous assurer que la fermeture ne viole pas les invariants de bibliothèque en créant des doublons non valides. Si vous fournissez une bibliothèque qui se trouve dans une situation similaire before_exec , pensez à l'obsolescence et offrez une alternative avec unsafe .
Stabilisation de bibliothèque
Dans la version 1.34.0, l'ensemble des types entiers atomiques signés et non signés stables a été étendu, commençant par 8 bits ( AtomicU8 ) et se terminant par 64 bits.
NonZeroU8 entiers non NonZeroU8 non NonZeroU8 tels que NonZeroU8 étaient auparavant stabilisés. Grâce à cela, l' Option<NonZeroU8> la même taille que u8 . Les versions signées telles que NonZeroI8 stabilisées dans cette version.
Les fonctions iter::from_fn et iter::successors stabilisées. Le premier vous permet de créer un itérateur à partir de FnMut() -> Option<T> . Pour récupérer de manière itérative des éléments à partir d'un vecteur, vous pouvez maintenant écrire from_fn(|| vec.pop()) . Pendant ce temps, la deuxième fonction crée un nouvel itérateur, où chaque élément suivant est calculé en fonction du précédent.
De plus, les API suivantes ont été stabilisées:
Voir les notes de version détaillées pour plus de détails.