La principale caractéristique de cette version est l’introduction de registres alternatifs cargo. La version inclut également le support de ? dans les tests de documentation, quelques améliorations pour # [attribut (..)], ainsi que la stabilisation de TryFrom.Registres alternatifs cargo
L’unité de compilation en Rust est le crate (caisse en anglais) contrairement au C par exemple, où c’est le fichier. Chacun des crates d’un projet peut utiliser une édition différente du langage. On peut, par exemple, créer un nouveau crate 2015 et utiliser un crate 2018, qui utilise de nouveaux mots-clés sans problèmes.
Le langage peut donc avoir des changements incompatibles sans que le code des utilisateurs n’en soit impacté.
Avant la version 1.0, Rust disposait d’un registre crate public, crates.io. Les gens publient des crate avec des cargo publish et il est facile d'inclure ces crate dans la section [dependencies] de votre fichier Cargo.toml.
Cependant, tout le monde ne veut pas publier ses crates dans crates.io. Les personnes qui gèrent du code propriétaire / à code source fermé ne peuvent pas utiliser crates.io, mais sont obligées d'utiliser des dépendances git ou path. Cela convient généralement aux petits projets, mais si vous avez beaucoup de crate à code source fermé au sein d'une grande entreprise, vous perdez l'avantage du support de gestion des versions fourni par crates.io.
Avec cette version, Cargo bénéficie de la prise en charge de plusieurs registres. Ces registres coexistent avec crates.io afin que vous puissiez écrire un logiciel dépendant à la fois des crates de crates.io et de votre registre personnalisé. Crate sur crates.io ne peut cependant pas dépendre de registres externes.
Pour utiliser un autre registre, vous devez ajouter ces lignes à votre fichier .cargo / config. Ce fichier peut être dans votre répertoire personnel (~ / .cargo / config) ou par rapport au répertoire du paquet.
| Code Rust : | Sélectionner tout |
1 2 | [registries] my-registry = { index = "https://my-intranet:8080/git/index" } |
Dépendre d'un crate d'un autre registre est facile. Lorsque vous spécifiez des dépendances dans votre fichier Cargo.toml, utilisez la clé de registre pour indiquer à Cargo que vous souhaitez récupérer le crate dans le registre de remplacement:
| Code Rust : | Sélectionner tout |
1 2 | [dependencies] other-crate = { version = "1.0", registry = "my-registry" } |
En tant qu’auteur de crate, si vous souhaitez publier votre crate dans un autre registre, vous devez d’abord enregistrer le jeton d’authentification dans ~ / .cargo / credentials à l’aide de la commande cargo login:
| Code Rust : | Sélectionner tout |
cargo login --registry=my-registry
Vous pouvez ensuite utiliser l'indicateur --registry pour indiquer le registre à utiliser lors de la publication:
| Code Rust : | Sélectionner tout |
cargo publish --registry=my-registry
Il existe une documentation sur la façon de gérer votre propre registre.
? dans les tests de documentation
La RFC 1937 proposait d'ajouter un support pour l'utilisation de l’opérateur ? dans les fonctions fn main (), # [test] et doctests, leur permettant de renvoyer Option<T> ou Result<T, E>, avec des valeurs d'erreur générant un code de sortie non nul dans le cas de fn main (), et un échec de test dans le cas des tests.
Le support dans fn main () et # [test] a été implémenté il y a plusieurs versions. Cependant, la prise en charge dans les tests de documentation était limitée aux doctests ayant un fn main () explicite.
Dans cette version, le support complet pour ? dans doctests a été ajouté. Maintenant, vous pouvez écrire ceci dans vos tests de documentation:
| Code Rust : | Sélectionner tout |
1 2 3 4 5 6 7 | /// ```rust /// use std::io; /// let mut input = String::new(); /// io::stdin().read_line(&mut input)?; /// # Ok::<(), io:Error>(()) /// ``` fn my_func() {} |
Vous devez toujours spécifier le type d'erreur utilisé au bas du test de la documentation.
Les attributs personnalisés acceptent les flux de jetons arbitraires
Les macros procédurales dans Rust peuvent définir les attributs personnalisés qu’elles consomment. Jusqu'à présent, de tels attributs étaient limités à des arbres de chemins et de littéraux selon une syntaxe spécifique, telle que:
| Code Rust : | Sélectionner tout |
1 2 3 4 5 | #[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 les flux de jetons arbitraires dans les délimiteurs. Par conséquent, vous ne pouviez pas écrire # [range (0..10)] ou # [bound (T: MyTrait)]. Les macro crate procédurales utiliseraient plutôt des chaînes pour spécifier des syntaxes comme celle-ci, par exemple. # [range ("0..10")].
Avec cette version de Rust, les attributs personnalisés # [attr ($ tokens)] acceptent maintenant les flux de jetons arbitraires dans $ tokens, ce qui les rapproche des macros. Si vous êtes l'auteur d'une macro crate procédurale, veuillez vérifier si la syntaxe de vos attributs personnalisés contient des chaînes inutiles et si elles peuvent être mieux exprimées avec des flux de jetons.
TryFrom et TryInto
Les traits TryFrom et TryInto ont été stabilisés pour permettre les conversions de type faillibles.
Par exemple, from_be_bytes et les méthodes associées sur les types entiers utilisent des tableaux, mais les données sont souvent lues par tranches. La conversion entre les tranches et les tableaux est fastidieuse à effectuer manuellement. Avec les nouveaux traits, cela peut être fait en ligne avec .try_into ().
| Code Rust : | Sélectionner tout |
let num = u32::from_be_bytes(slice.try_into()?);
Pour les conversions qui ne peuvent pas échouer, telles que u8 à u32, le type Infallible a été ajouté. Cela permet également une implémentation complète de TryFrom pour toutes les implémentations From existantes.
fn before_exec déprécié en faveur de unsafe fn pre_exec
Sur les systèmes de type Unix, la fonction CommandExt :: before_exec vous permet de planifier l’exécution d’une fermeture avant l’appel de exec.
La fermeture fournie sera exécutée dans le contexte du processus enfant après un fork. Cela signifie que des ressources, telles que des descripteurs de fichier et des régions mappées en mémoire, peuvent être dupliquées. En d'autres termes, vous pouvez maintenant copier une valeur d'un type non Copy dans un processus différent tout en conservant l'original dans le parent. Cela permet de provoquer un comportement indéfini et de casser les bibliothèques en supposant qu'il n'y ait pas de duplication.
La fonction before_exec aurait donc dû être marquée comme étant unsafe (non sécurisée). Dans cette version de Rust, l’équipe a déprécié fn before_exec au profit de unsafe fn pre_exec. Lorsque vous appelez CommandExt :: pre_exec, il est de votre responsabilité de vous assurer que la fermeture ne viole pas les invariants de la bibliothèque en faisant un usage invalide de ces doublons. Si vous fournissez une bibliothèque qui se trouve dans une situation similaire à before_exec, envisagez de la déprécier et de proposer une alternative unsafe également.
Source : note de version
Et vous ?
Quelles sont les options qui vous intéressent le plus ? Avez-vous déjà développé en Rust ? Par loisir ou par contrainte professionnelle ? Quel type d'application ? Comment trouvez-vous ce langage ?Voir aussi :
Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts L'équipe de npm choisit Rust pour gérer les goulots d'étranglement liés au CPU au détriment de Go, C, C++ et Java, voici les raisons de ce choix RustPython, un interpréteur Python écrit en Rust et compatible avec WebAssembly, est disponible, pourrait-il rivaliser avec CPython ? L'équipe de Rust dévoile la version 1.32.0 du langage de programmation l'allocateur de mémoire est supprimé par défaut