Discussion :

[Bill Fassinou]

Rust 1.58 est disponible avec la réduction du chemin de recherche sous Windows et étend les chaînes de format
ainsi que l'utilisation de #[must_use] dans la bibliothèque standard

L'équipe de développement du langage Rust a annoncé jeudi la disponibilité de Rust 1.58 avec de nouvelles fonctionnalités. Rust 1.58 est livrée avec une extension des chaînes de format, une modification du chemin de recherche sous Windows, une utilisation plus étendue de #[must_use] dans la bibliothèque standard, et quelques nouvelles stabilisations de la bibliothèque.

Extension des chaînes de format

Les chaînes de format peuvent prendre des arguments de l'environnement via un identifiant encadré par des accolades. Jusqu'à présent, ils devaient se trouver directement dans l'instruction et être identifiables par leur position ou leur nom. Avec Rust 1.58, les arguments peuvent aussi être définis au préalable dans la même portée, comme dans le petit exemple suivant tiré du blogue Rust :

Code Rust :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
// New in Rust 1.58:
 
let person = get_person();
// ...
println!("Hello, {person}!"); // captures the local `person`
 
// Already allowed before:
 
println!("Hello, {}!", get_person());        // implicit position
println!("Hello, {0}!", get_person());       // explicit index
println!("Hello, {person}!", person = get_person()); // named

Les identificateurs peuvent être utilisés non seulement pour des parties de texte, mais aussi pour des paramètres de formatage comme width$. Rust ne traite toutefois que les identificateurs purs. Si vous souhaitez utiliser des expressions ou d'autres intégrations complexes dans des chaînes de format, vous devez au préalable les attribuer à un identifiant ou intégrer l'expression directement dans l'instruction, comme c'était le cas jusqu'à présent.

Dans Rust 2021, lancé avec la version 1.56, l'intégration des identifiants fonctionne également dans les macros panic! que la version 1.57 avait stabilisé pour une utilisation étendue. En revanche, Rust 2015 et Rust 2018 traitent le contenu de panic!("{ident}") non pas comme une chaîne de format, mais comme une chaîne non formatée. En interaction avec les anciennes éditions, le compilateur émet donc un avertissement indiquant que la commande n'a probablement pas l'effet escompté.

Réduction du chemin de recherche des commandes Windows

Sous Windows, la dernière version de Rust réduit le chemin de recherche des fichiers exécutables. La structure std::process::Command n'inclut plus le répertoire courant. Ce comportement est dû au fonctionnement historique de l'API createProcess sous Windows. L'invite de commande sous Windows inclut également le répertoire actuel dans le chemin, alors que PowerShell ne le fait pas pour des raisons de sécurité.

Selon l'équipe, les créateurs du langage de programmation Go ont également reconnu la faille de sécurité en 2021. Depuis, la commande go-get ignore le répertoire actuel sous Windows. Avec cette adaptation, Rust supprime encore un autre héritage du chemin de recherche et n'inclut plus le répertoire système 16 bits de Windows.

Utilisation étendue de #[must_use] dans la bibliothèque standard

L'attribut #[must_use] peut être appliqué à des types ou à des fonctions lorsque le fait de ne pas les considérer explicitement ou de ne pas prendre en compte leur sortie est presque certainement un bogue. Cet attribut est utilisé depuis longtemps dans la bibliothèque standard pour des types comme Result, qui doivent être vérifiés pour les conditions d'erreur. Cela permet également de capturer des erreurs comme le fait de s'attendre à ce qu'une fonction mute une valeur sur place, alors qu'elle renvoie en fait une nouvelle valeur.

Selon l'équipe, la proposition a été approuvée en octobre 2021 pour vérifier et étendre l'application de #[must_use] dans toute la bibliothèque standard, en couvrant beaucoup plus de fonctions dont l'effet principal est la valeur de retour. Ceci est similaire à l'idée de pureté des fonctions, mais plus souple qu'une véritable caractéristique du langage. Certains de ces ajouts étaient présents dans la version 1.57, et maintenant dans la 1.58, l'effort est terminé.

API stabilisées

Les méthodes et implémentations de traits suivantes ont été stabilisées.

• Metadata::is_symlink ;
• Path::is_symlink ;
• {integer}::saturating_div ;
• Option::unwrap_unchecked ;
• Result::unwrap_unchecked ;
• Result::unwrap_err_unchecked ;
• File::options.

Les fonctions suivantes, auparavant stables, sont maintenant const.

• Duration::new ;
• Duration::checked_add ;
• Duration::saturating_add ;
• Duration::checked_sub ;
• Duration::saturating_sub ;
• Duration::checked_mul ;
• Duration::saturating_mul ;
• Duration::checked_div.

Comme d'habitude, les développeurs qui ont déjà installé Rust peuvent télécharger la version actuelle via la commande rustup update stable. Pour ceux qui n'utilisent pas encore Rust, l'outil rustup est disponible séparément sur la page de téléchargement.

Source : Rust 1.58

Et vous ?

Que pensez-vous des changements introduits par Rust 1.58 ?

Voir aussi

Rust peut-il sauver la planète ? Un composant JavaScript a été réécrit en Rust et aurait une amélioration de 50 % de la latence, une réduction de 75 % de l'utilisation du CPU et 95 % de la mémoire

L'édition Rust 2021 et la version stable Rust 1.56 sont maintenant disponibles en téléchargement, la nouvelle édition du langage inclut la prise en charge des captures disjointes

Rust 1.54 est disponible. Cette version vient étendre la connexion du langage à WebAssembly et permet l'utilisation de macros dans les attributs

[Pyramidev]

Rust 1.58.1 corrige une faille de sécurité, CVE-2022-21658, qui concerne std::fs::remove_dir_all de Rust 1.0.0 à Rust 1.58.0.

Plus de détails ici : https://blog.rust-lang.org/2022/01/2...022-21658.html

[Uther]

Ce qui est marrant c'est que ce problème existe aussi dans les principales bibliothèque standard C++, mais comme il ne prétend pas fournir un standard thread safe, ce n'est pas considéré comme un bug.

[Pyramidev]

Ce qui est marrant c'est que ce problème existe aussi dans les principales bibliothèque standard C++

En effet :

• GCC : https://github.com/gcc-mirror/gcc/bl...m/ops.cc#L1106
• LLVM (Clang) : https://github.com/llvm/llvm-project...ions.cpp#L1349
• Microsoft : https://github.com/microsoft/STL/blo...lesystem#L3825

Les liens viennent de https://www.reddit.com/r/cpp/comment...rabilities_in/ et https://www.reddit.com/r/cpp/comment...eb2x&context=3.
(Dans les URL pour GCC et LLVM, à la place de "master" et "main", j'ai mis des numéros de tag pour que les URL soient pérennes.)

mais comme il ne prétend pas fournir un standard thread safe, ce n'est pas considéré comme un bug.

Je présume que tu te bases sur le commentaire 14ned : https://www.reddit.com/r/cpp/comment...eb2x&context=3

std::filesystem was never designed nor intended to be safe to use on a filesystem which isn't 100% under the exclusive control of a single kernel thread in a single process system. That's by design.

Mais, lui-même, je me demande quelle est sa source.