IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

L'équipe Rust annonce une nouvelle version de Rust, 1.71.0.
Rust est un langage de programmation permettant à chacun de construire des logiciels fiables et efficaces

Le , par Sandra Coret

50PARTAGES

14  0 
Si vous avez une version précédente de Rust installée via rustup, vous pouvez obtenir la version 1.71.0 avec :

$ rustup update stable

Si vous ne l'avez pas encore, vous pouvez obtenir rustupà partir de la page appropriée sur notre site web, et consulter les notes de version détaillées pour la 1.71.0 sur GitHub.

Si vous souhaitez nous aider en testant les futures versions, vous pouvez envisager de mettre à jour localement pour utiliser le canal beta (rustup default beta) ou le canal nightly (rustup default nightly). N'hésitez pas à nous signaler les bugs que vous pourriez rencontrer !

Ce qu'il y a dans la version 1.71.0 stable

C-unwind ABI

La version 1.71.0 stabilise l'ABI C-unwind (et d'autres variantes d'ABI suffixées par -unwind).

Le comportement en cas de déroulement non forcé (le cas typique) est spécifié dans ce tableau tiré du RFC qui a proposé cette fonctionnalité. En résumé :

Chaque ABI est en grande partie équivalente à la même ABI sans -unwind, sauf qu'avec -unwind, le comportement est défini pour être sûr lorsqu'une opération de déroulement (panic ou exception de style C++) franchit la limite de l'ABI. Pour panic=unwind, il s'agit d'un moyen valide de laisser les exceptions d'un langage dérouler la pile dans un autre langage sans mettre fin au processus (tant que l'exception est attrapée dans le même langage que celui d'où elle provient) ; pour panic=abort, le processus sera typiquement interrompu immédiatement.

Pour cette stabilisation initiale, aucune modification n'est apportée aux ABIs existantes (par exemple "C"), et le déroulement à travers elles reste un comportement non défini. Une prochaine version de Rust modifiera ces ABIs pour qu'ils correspondent au comportement spécifié dans le RFC comme la dernière partie de la stabilisation de cette fonctionnalité (généralement l'abandon à la frontière). Les utilisateurs sont encouragés à commencer à utiliser les nouvelles variantes de l'ABI unwind dans leur code afin de rester à l'épreuve du temps s'ils ont besoin de dérouler à travers la frontière de l'ABI.

Attributs de visualisation du débogueur

1.71.0 stabilise le support d'un nouvel attribut,
#[debug_visualizer(natvis_file = "...")] et #[debug_visualizer(gdb_script_file = "...")], qui permet d'incorporer des descriptions Natvis et des scripts GDB dans les bibliothèques Rust afin d'améliorer la sortie du débogueur lors de l'inspection des structures de données créées par ces bibliothèques. Rust lui-même a intégré des scripts similaires depuis un certain temps pour la bibliothèque standard, mais cette fonctionnalité permet aux auteurs de bibliothèques de fournir une expérience similaire aux utilisateurs finaux.

Liaison raw-dylib

Sur les plateformes Windows, Rust supporte maintenant l'utilisation de fonctions provenant de bibliothèques dynamiques sans avoir besoin que ces bibliothèques soient disponibles au moment de la compilation, en utilisant la nouvelle option kind="raw-dylib" pour #[link].

Cela évite de demander aux utilisateurs d'installer ces bibliothèques (ce qui est particulièrement difficile pour la compilation croisée), et évite d'avoir à fournir des versions stub des bibliothèques dans les crates pour les lier. Cela simplifie les crates qui fournissent des liens vers les bibliothèques Windows.

Rust prend également en charge la liaison aux symboles fournis par les DLL par ordinal plutôt que par symbole nommé, en utilisant le nouvel attribut #[link_ordinal].

Mise à jour vers musl 1.2

Comme annoncé précédemment, Rust 1.71 met à jour la version musl en 1.2.3. La plupart des utilisateurs ne devraient pas être affectés par ce changement.

Locaux de threads initialisés par des constantes

Rust 1.59.0 a stabilisé le support des threads locaux à initialisation const dans la bibliothèque standard, ce qui permet une génération de code plus optimale.
Cependant, jusqu'à présent, cette fonctionnalité était absente des notes de version et de la documentation. Notez que cette stabilisation ne fait pas de const { ... } une expression ou une syntaxe valide dans d'autres contextes ; il s'agit d'une fonctionnalité distincte et actuellement instable.

Code : Sélectionner tout
1
2
3
4
5
use std::cell::Cell;

thread_local! {
    pub static FOO: Cell<u32> = const { Cell::new(1) };
}

Source : Rust

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

Rust, réalité et fiction : 5 leçons tirées de l'expérience Rust de Google en 2022, selon l'enquête de Lars Bergstrom et Kathy Brennan

Le langage Rust se dote d'un Conseil de direction suite aux plaintes de la communauté concernant des lacunes en matière de gouvernance, et la création d'un fork du langage par des protestataires

Rust 1.70.0, la nouvelle version du langage de programmation, est désormais disponible, et apporte plusieurs fonctionnalités stabilisées et une activation par défaut du protocole sparse de Cargo

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de fdecode
Membre régulier https://www.developpez.com
Le 17/07/2023 à 16:36
Citation Envoyé par Padget Voir le message
je pense qu'ils devraient arrêter cette manie des mise à jour tous 6 mois et profiter du fait que leur langage est maintenant mâture. ils pourraient se caler sur un modèle avec une vision plus long terme et faire des vrai grosse mise à jour tous les deux trois ans.
6 semaines, et non 6 mois. Avec des éditions jalonnant ces mises à jours apparemment tous les 3 ans.

En ce qui me concerne, ce rythme de mise à jour me vas très bien.

La partie mature du langage évolue très peu, et ne sera vraisemblablement pas remise en question sur le long terme, mais il existe toujours des parties en évolution ou dans une phase instable. Je ne vois pas l'intérêt d'attendre 3 ans pour la mise à jour de ces éléments, si ils deviennent stables.
3  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 17/07/2023 à 20:21
Citation Envoyé par Padget Voir le message
l'intérêt c'est que au lieu de publier une release aussi régulière, ils peuvent glisser les évolutions dans une branche expérimentale du langage afin qu'elles passent non seulement les tests du projet mais également les tests de la communauté.
Cela existe déjà en Rust : c'est le canal "nightly". Si tu parcours la documentation de la bibliothèque standard de Rust, tu verras écrit de temps en temps "This is a nightly-only experimental API." C'est par exemple encore le cas des itérateurs asynchrones.

Les trois canaux des releases de Rust sont "stable", "beta" et "nightly". Les détails sont expliqués dans l'article Stability as a Deliverable.

Pour préciser ce que dit fdecode, les éditions concernent les changements non rétrocompatibles. Plusieurs crates codés dans des éditions différentes peuvent quand même s'appeler entre eux. Ce système d'éditions est décrit dans le The Rust Edition Guide.
2  0 
Avatar de smarties
Membre expert https://www.developpez.com
Le 18/07/2023 à 9:33
Le rythme des MAJ me convient aussi sur la branche stable.
Même si je mets à jour régulièrement Rust, je n'utilise pas à tous les coups les améliorations non plus.

Le processus aussi est simple et peu contraignant :
Code : Sélectionner tout
rustup update
Le plus contraignant est de modifier dans les projets ses fichier TOML avec l'édition ou la MAJ manuelle des librairies (ce n'est pas tout à fait comme poetry pour Python mais c'est déjà bien, je chipote un peu).
0  0 
Avatar de Padget
Membre régulier https://www.developpez.com
Le 17/07/2023 à 19:17
Citation Envoyé par fdecode Voir le message
6 semaines, et non 6 mois. Avec des éditions jalonnant ces mises à jours apparemment tous les 3 ans.

En ce qui me concerne, ce rythme de mise à jour me vas très bien.

La partie mature du langage évolue très peu, et ne sera vraisemblablement pas remise en question sur le long terme, mais il existe toujours des parties en évolution ou dans une phase instable. Je ne vois pas l'intérêt d'attendre 3 ans pour la mise à jour de ces éléments, si ils deviennent stables.
l'intérêt c'est que au lieu de publier une release aussi régulière, ils peuvent glisser les évolutions dans une branche expérimentale du langage afin qu'elles passent non seulement les tests du projet mais également les tests de la communauté.
0  1 
Avatar de Padget
Membre régulier https://www.developpez.com
Le 15/07/2023 à 13:52
je pense qu'ils devraient arrêter cette manie des mise à jour tous 6 mois et profiter du fait que leur langage est maintenant mâture. ils pourraient se caler sur un modèle avec une vision plus long terme et faire des vrai grosse mise à jour tous les deux trois ans.
2  4