Discussion :

[Jade Emy]

La version 1.96.0 du langage de programmation Rust est disponible, apportant de nouveaux types Range*, de nouvelles macros stabilisées et des corrections de vulnérabilités dans Cargo

La version 1.96.0 du langage Rust introduit de nouveaux types core::range compatibles avec Copy, permettant d'utiliser des plages dans les structs Copy et d'exposer des champs publics dans RangeInclusive. Cette version stabilise également les macros assert_matches! et debug_assert_matches!, qui améliorent les diagnostics de correspondance de motifs, bien qu'elles nécessitent une importation manuelle.

Rust est un langage de programmation polyvalent qui met l'accent sur les performances, la sécurité des types, la concurrence et la sécurité de la mémoire. Rust prend en charge plusieurs paradigmes de programmation. Il s'inspire de concepts issus de la programmation fonctionnelle, notamment l'immuabilité, les fonctions d'ordre supérieur, les types de données algébriques et la correspondance de motifs. Il prend également en charge la programmation orientée objet via des structures, des énumérations, des traits et des méthodes. Rust garantit la sécurité de la mémoire (c'est-à-dire que toutes les références pointent vers une mémoire valide) sans recourir à un ramasse-miettes classique ; à la place, les erreurs de sécurité de la mémoire et les conflits d'accès sont évités par le « vérificateur d'emprunt », qui suit la durée de vie des objets référencés lors de la compilation.

La version 1.96.0 du langage Rust introduit de nouveaux types core::range compatibles avec Copy, permettant d'utiliser des plages dans les structs Copy et d'exposer des champs publics dans RangeInclusive. Cette version stabilise également les macros assert_matches! et debug_assert_matches!, qui améliorent les diagnostics de correspondance de motifs, bien qu'elles nécessitent une importation manuelle. Les cibles WebAssembly traitent désormais les symboles de l'éditeur de liens non définis comme des erreurs par défaut. Deux vulnérabilités de Cargo affectant les registres tiers sont également corrigées.

Voici les nouveautés de la version stable 1.96.0 :

Nouveaux types Range*.

De nombreux utilisateurs s'attendent à ce que Range et les types core::ops associés soient de type Copy, mais ce n'est pas le cas : ils implémentent directement Iterator, et il serait risqué d'implémenter à la fois Iterator et Copy sur le même type, ce qui a donc été évité. La RFC3550 proposait un ensemble de types Range de remplacement qui implémentent IntoIterator plutôt qu'Iterator, ce qui signifie qu'ils peuvent également être de type Copy. La partie de cette RFC concernant la bibliothèque standard est désormais stable, introduisant :

- core::range::Range,
- core::range::RangeFrom,
- core::range::RangeInclusive.
- Itérateurs associés

Une version de Rust à venir ajoutera également core::range::RangeFull et core::range::RangeTo en tant que réexportations depuis core::ops (ces derniers n'implémentent pas Iterator et implémentent déjà Copy), ainsi que core::range::legacy::* en tant que nouvel emplacement pour les plages actuelles. La syntaxe de plage telle que 0..1 produit encore les types hérités pour l'instant, mais sera mise à jour vers les types core::range dans une future édition.

Grâce à ces stabilisations, il est désormais possible de stocker des accesseurs de tranche dans des types Copy sans séparer start et end :

Code :

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

1
2
3
4
5
6
7
8
9
10
use core::range::Range;
 
#[derive(Clone, Copy)]
pub struct Span(Range<usize>);
 
impl Span {
    pub fn of(self, s: &str) -> &str {
        &s[self.0]
    }
}

Le nouveau RangeInclusive rend également ses champs publics, contrairement à l'ancienne version qui évitait d'exposer l'état d'itérateur épuisé. Cela ne pose pas de problème avec le nouveau type, car celui-ci doit être converti pour pouvoir commencer l'itération.

Les auteurs de bibliothèques devraient envisager d'utiliser impl RangeBounds dans leur API publique, qui accepte à la fois les anciens types de plage et les nouveaux. Si un type concret est nécessaire, privilégiez l'utilisation des nouvelles plages, car celles-ci finiront par devenir la norme.

Assertions de correspondance de motifs

Les nouvelles macros assert_matches! et debug_assert_matches! vérifient qu’une valeur correspond à un motif donné, et déclenchent une panique avec une représentation Debug de la valeur dans le cas contraire. Elles sont essentiellement identiques à assert!(matches!(..)) et debug_assert!(matches!(..)), mais la valeur affichée améliore les chances de diagnostiquer l’échec.

Ces nouvelles macros n’ont pas été ajoutées au prélude standard, car elles entreraient en conflit avec des crates tierces populaires fournissant des macros du même nom. Elles doivent donc être importées manuellement depuis core ou std avant utilisation.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
use core::assert_matches;
 
/// [Random Number](https://xkcd.com/221/)
fn get_random_number() -> u32 {
    // chosen by a fair dice roll.
    // guaranteed to be random.
    4
}
 
fn main() {
    assert_matches!(get_random_number(), 1..=6);
}

Modifications apportées aux cibles WebAssembly

Les cibles WebAssembly ne transmettent plus l'option --allow-undefined à l'éditeur de liens, ce qui signifie que les symboles non définis lors de la liaison génèrent désormais une erreur d'éditeur de liens au lieu d'être convertis en importations WebAssembly à partir du module "env". Cette modification empêche la liaison des modules tant que tous les symboles liés à la liaison ne sont pas définis, afin de détecter les bogues plus tôt et d'éviter les problèmes accidentels liés à la dénomination des symboles ou autres.

Les symboles liés à la liaison non définis sont souvent le signe de bogues liés à la compilation ou d’une mauvaise configuration. Si, toutefois, l’ancien comportement est souhaité, il peut être réactivé avec RUSTFLAGS=-Clink-arg=--allow-undefined ou en modifiant le code source et en utilisant #[link(wasm_import_module = « env »)] sur le bloc définissant le symbole.

Ce changement avait été annoncé précédemment et prend désormais effet dans Rust 1.96.

Deux avis de sécurité concernant Cargo

Rust 1.96 contient des correctifs pour deux vulnérabilités affectant les utilisateurs de registres tiers.

- CVE-2026-5223 est une vulnérabilité de gravité moyenne concernant l'extraction d'archives de crates contenant des liens symboliques.
- CVE-2026-5222 est une vulnérabilité de gravité faible concernant l'authentification avec des URL normalisées.

Les utilisateurs de crates.io ne sont affectés par aucune de ces vulnérabilités.

Source : Annonce de Rust 1.96.0

Et vous ?

Pensez-vous que cette version est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Rust a-t-il atteint son plafond de popularité ? Le langage recule de trois places dans l'index TIOBE d'avril 2026. Son PDG évoque une « courbe d'apprentissage difficile pour les développeurs non experts »

Submergé par les bugs dans ses applications, la solution de Microsoft c'est de supprimer tout le code C et C++ de ses référentiels d'ici 2030, pour le remplacer par Rust

« Rust sauvera Linux de l'IA », affirme Greg Kroah-Hartman dans le cadre d'une critique de l'usage de l'intelligence artificielle pour trouver les bogues au sein du code du noyau écrit en langage C

[OuftiBoy]

à toutes et tous, et à Uther

Je vois que Rust introduit le type "Range", c'est exactement (si j'ai bien compris l'article), la même idée que j'ai eue pour mon petit langage Home.
J'ai déjà introduit cela dans le code et dans la génération de l'IRC. Là je suis en train de voir comment passer ces ranges à une fonction, j'ai pas encore la solution complète, mais je sens bien que j'y arrive tout doucement... C'est une très bonne idée de l'équipe Rust, et moi ça me donne confiance dans le développement de mon langage et de sont compilateur de lire ce genre de news

BàV et Peace & Love

[fdecode]

Je vois que Rust introduit le type "Range", c'est exactement (si j'ai bien compris l'article),

Bonjour OuftiBoy!

Les ranges existent depuis longtemps. Déjà présent dans la version 1.0 de 2015.

• Depuis 1.0 : https://doc.rust-lang.org/std/ops/struct.Range.html
• Depuis 1.96 : https://doc.rust-lang.org/std/range/struct.Range.html

Là il s'agit d'une version alternative qui permet la copie. On dirait que ces versions remplaceront les anciennes pour certaines fonctionnalités, mais quoiqu'il en soit, ces nouveaux range ne sont pas des itérateurs, mais peuvent être transformés en itérateurs (la différence entre implémenter le trait 'Iterator' ou implémenter le trait 'IntoIterator').

Et bon courage pour ton langage.

[OuftiBoy]

fdecode,

Les ranges existent depuis longtemps. Déjà présent dans la version 1.0 de 2015.

• Depuis 1.0 : https://doc.rust-lang.org/std/ops/struct.Range.html
• Depuis 1.96 : https://doc.rust-lang.org/std/range/struct.Range.html

Là il s'agit d'une version alternative qui permet la copie. On dirait que ces versions remplaceront les anciennes pour certaines fonctionnalités, mais quoiqu'il en soit, ces nouveaux range ne sont pas des itérateurs, mais peuvent être transformés en itérateurs (la différence entre implémenter le trait 'Iterator' ou implémenter le trait 'IntoIterator').

Je n'avais pas vu cela, je m'étais attardé plus sur la protection mémoire. Mais a y regarder de plus près, ce que je fais est plus "basic". Mes "ranges" permettent de ne jamais pouvoir déborder d'un tableau (à la compilation), et d'éviter des type 'underflow' ou 'overflow' (à la compilation). Le compilateur 'trace' chaque utilisation des variables, quelle qu'elles soient, et émet une erreur si un 'risque' existe. Pour que la vérification se fasse dès compilation, le compilateur 'connait' ce que l'on peut encore 'retirer' ou 'ajouter' à une variable. C'est très précis avec des constantes, et un peut moins si ne connait que le max d'une variable. C'est pour ça que je n'utilise pas les 'types machine', remplacés par mes 'ranges' dont on peut définir la plage très précisément.

Lors de la génération de l'IRC j'utilise évidemment des 'types' machine, mais le compilateur a valider les 'bornes' de chaque variable avant.

Et bon courage pour ton langage.

J'avance bien, j'alterne entre faire avancer le compilateur, le langage, et la doc (qui prend vite du temps).

BàT et Peace & Love.

[Uther]

En effet la notion de range dans ton langage, de ce que j'en est compris est plus proche des range d'Ada : une limitation définie à la compilation des valeurs possible sur un type.
Les range en Rust sont juste des types normaux (struct) qui représentant un intervalle. mais sans grand chose de particulier à part une écriture abrégée.

[fdecode]

En effet la notion de range dans ton langage, de ce que j'en est compris est plus proche des range d'Ada : une limitation définie à la compilation des valeurs possible sur un type.
Les range en Rust sont juste des types normaux (struct) qui représentant un intervalle. mais sans grand chose de particulier à part une écriture abrégée.

On peut faire des ranged type maison en Rust [playground]:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#[repr(transparent)]
#[derive(Clone, Copy, Debug, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub struct RangedI128<const MIN: i128, const MAX: i128>(i128);
 
impl<const MIN: i128, const MAX: i128> RangedI128<MIN, MAX> {
    const _ASSERT_BOUNDS: () = assert!(MAX >= MIN);
 
    pub const fn try_new(x: i128) -> Option<Self> {
        let _ = Self::_ASSERT_BOUNDS;
        if x < MIN || x > MAX {
            None
        } else {
            Some(Self(x))
        }
    }
 
    pub const fn get(self) -> i128 {
        self.0
    }
}

Ça pourrait être un peu mieux, mais on est limité par les capacités actuelles des génériques constants.