Les erreurs du compilateur Rust les plus couramment rencontrées dans RustRover

Rust fait une distinction stricte entre les sites de déclaration de type et les utilisations de nom de type. Chaque nom de type (y compris les types génériques) doit être déclaré quelque part et être disponible dans la portée dans laquelle il est utilisé. Lorsque le compilateur rencontre une utilisation de nom de type et n’a pas d’information sur son site de déclaration, il émet l’erreur E0412. Environ 12 % des utilisateurs de RustRover ont déjà fait l’expérience de cette erreur.

Imaginons que vous ayez saisi i42 au lieu de i32.

RustRover détecte ce problème et met en évidence le nom de type inconnu. Le compilateur donne plus de détails et propose un correctif qui peut être facilement appliqué en cliquant sur le bouton Apply fix dans la sortie du compilateur :

Une erreur E0412 peut se produire dans d’autres situations, notamment :

• si l’on oublie de déclarer un type ;
• lorsqu’un type est importé dans la portée actuelle.

En cas d’introduction d’un nom de type générique qui rend le type inaccessible au compilateur.

Pour résoudre le problème, vous pouvez fournir une déclaration de type (déclarer un struct ou introduire un nom de type générique correctement) ou amener le type dans une portée (via la clause use). L’explication officielle de l’erreur E0412 donne plus d’exemples.

Bien que RustRover connaisse cette erreur et fournisse plusieurs correctifs, 13 % des utilisateurs la laissent passer et omettent de la corriger avant la création de leurs projets.

L’intitulé de cette erreur est assez explicite : une fonction est déclarée dans la portée actuelle ou importée depuis un autre endroit, et le site d’appel donne trop ou trop peu d’arguments. Voyons-en un exemple et comparons les suggestions de RustRover à celles du compilateur Rust :

Si l’on a l’habitude de programmer avec un autre langage, on pourrait être tenté de fournir un deuxième argument, en oubliant qu’en Rust, cette méthode n’en prend qu’un seul. RustRover et le compilateur Rust nous invitent donc à supprimer le second argument. Il est appréciable de bénéficier de cette suggestion de la part de l’IDE avant d’avoir créé le projet. Prêtez attention aux lignes de soulignement rouges ondulées dans votre code : généralement, elles sont là pour une bonne raison !

La situation devient plus intéressante si la fonction que nous appelons est définie dans notre propre code. Supposons que nous continuons de travailler sur le même exemple de code :

Dans ce cas, RustRover suggère comme première solution d’ajouter un paramètre à la fonction, ce qui peut faire sens. Le compilateur Rust insiste quant à lui pour le supprimer. Cette divergence a une explication logique. Le travail du compilateur consiste à s’assurer que le programme est correct, et le moyen le plus facile d’y parvenir consiste à éliminer l’argument supplémentaire sur le site de l’appel. En revanche, la mission de l’IDE est de vous accompagner vers la réalisation de votre objectif. Si vous avez saisi cet argument pour votre fonction, RustRover considère qu’il est probable que cela soit volontaire et tente donc de vous aider à terminer ce que vous avez commencé.

Parfois le compilateur est perdu : il ne trouve pas quel est le type requis pour une variable et ne peut que suggérer d’ajouter une annotation manuellement. Si vous avez déjà rencontré cette erreur, bienvenue au club : 13,5 % des utilisateurs de RustRover y ont déjà été confrontés.

La source principale des erreurs telles que E0282 est la généricité. De nombreuses fonctions de bibliothèques utilisent des paramètres de type générique, mais le compilateur doit instancier ces paramètres en type concret, ce qui est source de confusion pour lui. Prenons l’exemple suivant :

Ici nous devons collecter des nombres à partir d’une chaîne dans un conteneur. Malheureusement, le compilateur ne peut pas déterminer le type des nombres ou le genre de conteneur dont il s’agit.

Le compilateur suggère la spécification du type de conteneur en premier. Cependant, si nous appliquons ce correctif, nous obtiendrons de nouveau le même genre d’erreur, mais concernant str::parse cette fois. collect et parse sont des méthodes génériques, mais le compilateur a besoin de connaître le type précis afin de compiler le code qui les utilise. Veuillez noter que RustRover ne met pas les erreurs en évidence, car nous travaillons encore au perfectionnement de sa fonctionnalité de vérification de type.

Il existe plusieurs façons de corriger le problème, parce qu’une annotation de type peut être ajoutée à différents endroits. Nous pouvons spécifier le type concret du vecteur numbers :

let numbers: let numbers: Vec = "1 5 6 3"

Ou nous pouvons mentionner le même type lors de l’appel de collect:

Enfin, nous pouvons mentionner différents types à différents endroits :

let numbers = GUILLEMET-KITOOODVP1  5     6   3GUILLEMET-KITOOODVP
   .split_whitespace()
   .map(str::parse::)
   .map(Result::unwrap)
   .collect::<Vec>();

Cette erreur est facile à corriger : il suffit de spécifier le type ou les types que vous voulez.

RustRover fournit de nombreuses fonctionnalités de saisie semi-automatique. Commençons par exemple en introduisant une expression régulière dans notre code :

Si vous choisissez la première suggestion, deux autres choses vont se produire en plus de la saisie semi-automatique elle-même :

• une dépendance de la crate regex sera ajoutée à votre fichier Cargo.toml ;
• une clause use regex::Regex; sera ajoutée en haut du fichier.

Lorsque vous ajoutez des clauses d’utilisation comme cela, les importations sont écrites automatiquement et correctement. Mais il faut parfois écrire les importations manuellement et c’est là que l’erreur E0432 risque de se produire. 15,5 % des utilisateurs de RustRover la rencontrent occasionnellement, le plus souvent en cas de faute dans le nom d’une crate ou d’un module, de tentative d’importation de quelque chose d’inexistant ou de présence d’une clause use erronée dans le code après l’avoir copiée/collée à partir d’un autre endroit. La première suggestion est de toujours vérifier les dépendances et les noms.

Parfois, RustRover peut nous aider à éviter cette erreur. S’il a connaissance de la crate que nous tentons d’importer, il suggère l’ajout d’une dépendance lorsque vous collez du code depuis des sources externes ou fournit une assistance grâce aux correctifs rapides suivants :

L’ajout de la dépendance correspondante à Cargo.toml corrige l’erreur immédiatement. Une fois que la crate est disponible, il est plus sûr d’utiliser la saisie semi-automatique pour les autres composants du chemin dans les clauses use, afin d’éviter la survenance de nouveaux problèmes avec les noms. Rappelez-vous aussi que la disponibilité de certains noms peut dépendre des fonctionnalités de la crate qui sont activées.

Il peut également y avoir des problèmes avec les noms de chemin spéciaux tels que super ou crate, notamment parce qu’ils sont traités différemment dans les différentes versions de Rust. Vous trouverez plus d’informations à ce sujet dans l’explication officielle.

Point intéressant : les problèmes liés à la possession ! 17 % des utilisateurs de RustRover ont déjà rencontré cette erreur. L’explication officielle est très détaillée et donne de nombreux exemples. Malheureusement, RustRover n’est pas d’une grande aide dans ce cas. Si un linter externe est désactivé, le mécanisme interne de RustRover ne voit aucun problème dans le code suivant :

fn main() {
   let vec = vec![1, 2, 3, 4, 5];
   let mut sum = 0;
   for v in vec {
       sum += v;
   }
   println!(GUILLEMET-KITOOODVPSum of {vec:?} elements is {sum}GUILLEMET-KITOOODVP);
}

Ce code d’aspect anodin serait parfaitement légitime dans certains autres langages de programmation. Nous avons un vecteur et voulons calculer la somme de ses éléments. Si vous travaillez habituellement avec C et que vous ne connaissez pas les astuces de programmation liées aux itérateurs, vous écririez plutôt une boucle for traditionnelle à la place. Une fois les éléments ajoutés, il n’y aurait alors plus qu’à imprimer le vecteur et le résultat des calculs. Exact ?

Eh bien ce n’est pas le cas avec Rust à cause des règles de la possession propres au langage.

Le problème est que la source de données dans la boucle for est étendue à l’appel into_iter(), qui prend alors possession de l’ensemble du vecteur. Par conséquent, lorsque nous tenterons ensuite d’accéder aux éléments du vecteur dans println!, le compilateur indiquera qu’il a été déplacé.

Le correctif proposé par le navigateur est simple : itérer sur &vec pour éviter de le déplacer dans la boucle, puis l’emprunter.

En général, il est utile de conserver constamment une trace des règles de possession des valeurs. Le déplacement et l’emprunt de valeurs sont des concepts fondamentaux de Rust. Il est important pour les néophytes d’assimiler ces concepts dès le début.

Dans cette première partie, nous avons passé en revue certaines des erreurs du compilateur Rust les plus fréquentes en nous basant sur les données d’utilisation de RustRover. Dans la prochaine partie, nous verrons les 5 erreurs les plus fréquentes et tenterons de répondre à une question que se posent tous les développeurs Rust : « Quelle partie de Rust cause le plus de problèmes ? ».