Rust 1.89 est désormais disponible et étend la prise en charge des plateformes x86 et x86/x86_64 avec de nouvelles instructions et fonctionnalités de processeur, dont des intrinsèques AVX-512 supplémentairesRust 1.89 est maintenant disponible, étendant le support des plateformes x86 et x86/x86_64 avec de nouvelles instructions et fonctionnalités de processeur, y compris des intrinsèques AVX-512 supplémentaires. Les principales nouveautés et améliorations apportées par la version 1.89.0 stable de Rust sont présentés dans ce qui suit.
L'attribut target_feature ajoute le support de SHA512, SM3, SM4, KL, et WIDEKL, donnant aux développeurs un meilleur accès aux capacités des processeurs modernes directement à partir du code Rust.
La mise à jour stabilise également plusieurs API, introduit des avertissements (lints) pour les syntaxes de durée de vie (lifetime) non concordantes, et autorise le caractère underscore (_) comme argument dans les paramètres génériques const.
La prise en charge des plateformes change également, la cible x86_64-apple-darwin passant au niveau 2, Apple et GitHub ayant réduit la prise en charge de macOS x86_64. Cette version comprend en outre des améliorations mineures du compilateur et des outils qui améliorent l'expérience globale de développement.
Si vous avez une version précédente de Rust installée via rustup, vous pouvez obtenir la version 1.89.0 avec :
| Code : | Sélectionner tout |
$ rustup update stable
Si vous ne l'avez pas encore, vous pouvez obtenir rustup à partir de la page appropriée sur le site web de Rust.
Arguments explicitement inférés des génériques const
Rust supporte maintenant _ comme argument des paramètres génériques const, en inférant la valeur du contexte environnant :
| Code Rust : | Sélectionner tout |
1 2 3 | pub fn all_false<const LEN: usize>() -> [bool; LEN] { [false; _] } |
De la même manière que pour les règles concernant les cas où _ est autorisé en tant que type, _ n'est pas autorisé en tant qu'argument des paramètres génériques const lorsqu'il se trouve dans une signature :
| Code Rust : | Sélectionner tout |
1 2 3 4 5 6 7 | // This is not allowed pub const fn all_false<const LEN: usize>() -> [bool; _] { [false; LEN] } // Neither is this pub const ALL_FALSE: [bool; _] = all_false::<10>(); |
Avertissements pour les syntaxes lifetime non concordantes
L'élision des lifetimes dans les signatures de fonctions est un aspect ergonomique du langage Rust, mais il peut aussi être un point d'achoppement pour les nouveaux venus comme pour les experts. Ceci est particulièrement vrai lorsque les lifetimes sont déduites dans des types où il n'est pas syntaxiquement évident qu'une durée de vie soit présente :
| Code Rust : | Sélectionner tout |
1 2 3 4 5 6 7 8 | // The returned type `std::slice::Iter` has a lifetime, // but there's no visual indication of that. // // Lifetime elision infers the lifetime of the return // type to be the same as that of `scores`. fn items(scores: &[u8]) -> std::slice::Iter<u8> { scores.iter() } |
Un code comme celui-ci produira désormais un avertissement par défaut :
| Code Rust : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | warning: hiding a lifetime that's elided elsewhere is confusing --> src/lib.rs:1:18 | 1 | fn items(scores: &[u8]) -> std::slice::Iter<u8> { | ^^^^^ -------------------- the same lifetime is hidden here | | | the lifetime is elided here | = help: the same lifetime is referred to in inconsistent ways, making the signature confusing = note: `#[warn(mismatched_lifetime_syntaxes)]` on by default help: use `'_` for type paths | 1 | fn items(scores: &[u8]) -> std::slice::Iter<'_, u8> { | +++ |
L'équipe Rust a d'abord tenté d'améliorer cette situation en 2018 dans le cadre du groupe de lint rust_2018_idioms, mais de nombreux commentaires sur le lint elided_lifetimes_in_paths ont montré qu'il s'agissait d'un marteau trop émoussé, car il avertit des durées de vie qui n'ont pas d'importance pour la compréhension de la fonction :
| Code Rust : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | use std::fmt; struct Greeting; impl fmt::Display for Greeting { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { // -----^^^^^^^^^ expected lifetime parameter // Knowing that `Formatter` has a lifetime does not help the programmer "howdy".fmt(f) } } |
L'équipe a alors réalisé que la confusion qu'elle souhaitait éliminer se produisait lorsque les deux règles d'inférence d'élision de la durée de vie reliaient la fonction
- les règles d'inférence d'élision de durée de vie connectent une durée de vie d'entrée à une durée de vie de sortie
- il n'est pas syntaxiquement évident qu'une durée de vie existe
Deux éléments de la syntaxe Rust indiquent l'existence d'une durée de vie : & et ', ' étant subdivisé en durée de vie déduite '_ et en durées de vie nommées 'a. Lorsqu'un type utilise une durée de vie nommée, l'élision de durée de vie ne déduira pas de durée de vie pour ce type. En utilisant ces critères, il est possible de construire trois groupes :
Le lint mismatched_lifetime_syntaxes vérifie que les entrées et les sorties d'une fonction appartiennent au même groupe. Pour l'exemple motivant ci-dessus, &[u8] appartient au deuxième groupe alors que std::slice::Iter<u8> appartient au premier groupe. On dira que les durées de vie du premier groupe sont cachées.
Parce que les durées de vie en entrée et en sortie appartiennent à des groupes différents, le lint avertira de cette fonction, réduisant ainsi la confusion sur le fait qu'une valeur a une durée de vie significative qui n'est pas visuellement évidente.
Le lint mismatched_lifetime_syntaxes remplace le lint elided_named_lifetimes, qui faisait quelque chose de similaire pour les durées de vie nommées spécifiquement.
Les travaux futurs sur le lint elided_lifetimes_in_paths ont pour but de le diviser en sous-lints plus ciblés afin d'avertir éventuellement sur un sous-ensemble d'entre eux.
Plus de fonctionnalités cibles x86
L'attribut target_feature prend désormais en charge les fonctionnalités cibles sha512, sm3, sm4, kl et widekl sur x86. En outre, un certain nombre d'intrinsèques et de caractéristiques cibles avx512 sont également prises en charge sur x86 :
| Code Rust : | Sélectionner tout |
1 2 3 4 | #[target_feature(enable = "avx512bw")] pub fn cool_simd_code(/* .. */) -> /* ... */ { /* ... */ } |
Doctests intercompilés
Les doctests seront désormais testés lors de l'exécution de cargo test --doc --target other_target, ce qui peut entraîner un certain nombre de ruptures dues au fait que des doctests qui auraient dû échouer sont désormais testés.
Les tests qui échouent peuvent être désactivés en annotant le doctest avec ignore-<target> (docs) :
| Code Rust : | Sélectionner tout |
1 2 3 4 | /// ```ignore-x86_64 /// panic!("something") /// ``` pub fn my_function() { } |
i128 et u128 dans les fonctions extern "C"
i128 et u128 ne déclenchent plus le lint improper_ctypes_definitions, ce qui signifie que ces types peuvent être utilisés dans des fonctions extern "C" sans avertissement. Cela s'accompagne de quelques mises en garde :
- Les types Rust sont ABI- et layout-compatibles avec (unsigned) __int128 en C lorsque le type est disponible.
- Sur les plateformes où __int128 n'est pas disponible, i128 et u128 ne sont pas nécessairement alignés avec un type C.
- i128 n'est pas nécessairement compatible avec _BitInt(128) sur n'importe quelle plateforme, parce que _BitInt(128) et __int128 peuvent ne pas avoir la même ABI (comme c'est le cas sur x86-64).
Source : Rust 1.89.0
Et vous ?
Quel est votre avis sur le sujet ? Trouvez-vous les nouveautés apportées par Rust 1.89 utiles et pertinentes ?Voir aussi :
La version 1.83 du langage de programmation Rust est disponible, introduisant de nouvelles capacités constantes, de nouvelles fonctions stables et des API stabilisées La version 1.76.0 de Rust, le langage de programmation compilé multi-paradigme, est disponible, et apporte une nouvelle documentation sur la compatibilité ABI, ainsi que d'autres améliorations La Fondation Rust publie un nouveau document pour améliorer l'interopérabilité entre Rust et C++, après le lancement de l'« Interop Initiative » en février 2024 avec une contribution de 1 million de $ de Google
Vous avez lu gratuitement 2 613 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.