{"id":443544,"date":"2024-02-13T09:40:51","date_gmt":"2024-02-13T08:40:51","guid":{"rendered":"https:\/\/blog.jetbrains.com\/?post_type=rust&p=443544"},"modified":"2024-02-13T09:46:16","modified_gmt":"2024-02-13T08:46:16","slug":"les-erreurs-du-compilateur-rust-les-plus-couramment-rencontrees-dans-rustrover-2eme-partie","status":"publish","type":"rust","link":"https:\/\/blog.jetbrains.com\/fr\/rust\/2024\/02\/13\/les-erreurs-du-compilateur-rust-les-plus-couramment-rencontrees-dans-rustrover-2eme-partie\/","title":{"rendered":"Les erreurs du compilateur Rust les plus couramment rencontr\u00e9es dans RustRover\u00a0– 2\u00e8me Partie"},"content":{"rendered":"

Les donn\u00e9es d’utilisation de RustRover nous ont permis d’identifier les 10 erreurs du compilateur Rust les plus fr\u00e9quentes, que nous avons commenc\u00e9 \u00e0 examiner dans un premier article<\/a>. Dans ce second article, nous poursuivons avec l’examen du top 5 de ces erreurs et abordons les aspects du langage Rust qui posent le plus de probl\u00e8mes aux d\u00e9veloppeurs avec le compilateur.<\/p>\n

Erreur fr\u00e9quente n\u00b0\u00a05\u00a0: E0433 (Utilisation d’une crate, d’un module ou d’un type non d\u00e9clar\u00e9<\/em>)<\/h2>\n

Cette erreur est similaire \u00e0 l’erreur E0432 (Une importation n’a pas \u00e9t\u00e9 r\u00e9solue), que nous avons vue dans l’article pr\u00e9c\u00e9dent. La seule diff\u00e9rence ici est qu’un chemin avec un composant probl\u00e9matique est utilis\u00e9 directement dans un nom, sans la clause use<\/code>. 17,5\u00a0% des utilisateurs de RustRover ont rencontr\u00e9 cette erreur. Dans l’exemple de code ci-dessous, le compilateur ne comprend pas s’il s’agit d’une crate ou d’un module et nous le fait savoir\u00a0:<\/p>\n

\"\"<\/figure>\n

Cet exemple montre pourquoi les messages d’erreur de Rust sont autant appr\u00e9ci\u00e9s. M\u00eame sans lire le message, le correctif \u00e0 apporter est \u00e9vident\u00a0: v\u00e9rifier les noms, ajouter les d\u00e9pendances requises \u00e0 Cargo.toml<\/kbd> si n\u00e9cessaire ou introduire les importations appropri\u00e9es.<\/p>\n

De son c\u00f4t\u00e9, RustRover permet de choisir les noms import\u00e9s.\u00a0<\/p>\n

\"\"<\/figure>\n
\"\"<\/figure>\n

L’utilisation de la saisie semi-automatique de code durant la saisie permet d’\u00e9viter cette erreur.\u00a0<\/p>\n

Erreur fr\u00e9quente n\u00b0\u00a04\u00a0: E0425 (Un nom non r\u00e9solu a \u00e9t\u00e9 utilis\u00e9<\/em>)<\/h2>\n

Poursuivons avec une autre erreur de la cat\u00e9gorie \u00ab\u00a0non r\u00e9solu\u00a0\u00bb. 20,5\u00a0% des utilisateurs de RustRover ont d\u00e9j\u00e0 \u00e9t\u00e9 dans une situation dans laquelle ils ont utilis\u00e9 un nom non r\u00e9solu, qui n’\u00e9tait syntaxiquement ni une crate ni un module. Voici ce que l’ont peut voir lorsque cette erreur survient\u00a0:<\/p>\n

\"\"<\/figure>\n

\u00c9videmment, lorsque cela arrive, le contexte n’est pas toujours aussi simple que dans cet exemple.<\/p>\n

H\u00e9las, m\u00eame l’excellent compilateur de Rust n’est pas d’une grande aide face \u00e0 cette erreur. Plusieurs approches\u00a0sont possibles ici : r\u00e9viser le nom, fournir une d\u00e9finition ou introduire des importations correctes.<\/p>\n

Erreur fr\u00e9quente n\u00b0\u00a03\u00a0: E0599 (Une m\u00e9thode est utilis\u00e9e sur un type qui ne l’impl\u00e9mente pas<\/em>)<\/h2>\n

Au risque de g\u00e2cher la surprise, \u00e0 partir de maintenant, toutes les erreurs porteront sur la v\u00e9rification de type\u00a0! En effet, les trois erreurs les plus fr\u00e9quentes sont toutes li\u00e9es \u00e0 une utilisation de type incorrecte. Concernant l’erreur #3, 27,5\u00a0% des utilisateurs de RustRover ont tent\u00e9 d’appeler une m\u00e9thode sur une valeur de type qui n’impl\u00e9mente pas cette m\u00e9thode. Examinons l’exemple suivant\u00a0:<\/p>\n

fn main() {\n\u00a0\u00a0\u00a0let numbers: Vec = vec![4, 11, 15, 12];\n\u00a0\u00a0\u00a0let sum: usize = numbers.sum();\n\u00a0\u00a0\u00a0println!(\"Answer = {sum}\");\n}<\/pre>\n
Tout semble correct, sauf qu’il n’y a pas de m\u00e9thode sum<\/code> pour Vec<\/code>. Voici le contenu exact du message d’erreur\u00a0:<\/p>\n
error[E0599]: `Vec` is not an iterator<\/pre>\n
Dans ce cas, il faut appeler une m\u00e9thode iter<\/code> en premier, puis utiliser sum<\/code> sur l’it\u00e9rateur r\u00e9sultant.\u00a0<\/p>\n
RustRover dispose d’une fonctionnalit\u00e9 qui permet d’\u00e9viter ce genre d’erreur : la saisie semi-automatique cha\u00een\u00e9e<\/em>. Voici un exemple de ce que cela donne\u00a0:<\/p>\n
\"\"<\/figure>\n
Lorsque la suggestion de saisie semi-automatique est accept\u00e9e, les m\u00e9thodes iter<\/code> et sum<\/code> sont ajout\u00e9es \u00e0 la cha\u00eene d’appels, ce qui corrige imm\u00e9diatement le code.<\/p>\n
En g\u00e9n\u00e9ral, la saisie semi-automatique \u00e9vite de recevoir un message d’erreur E0599. Si vous ne voyez pas de suggestion pour appeler la m\u00e9thode dont vous avez besoin, il est possible que le probl\u00e8me r\u00e9el provienne en r\u00e9alit\u00e9 du fait que le type de l’appel\u00e9 est incorrect.<\/p>\n
Un autre aspect de cette m\u00e9thode vaut la peine d’\u00eatre mentionn\u00e9\u00a0: dans de nombreux contextes, vous avez le contr\u00f4le sur vos propres d\u00e9clarations de type. Vous pouvez notamment appeler une m\u00e9thode en premier et demander ensuite \u00e0 RustRover de proc\u00e9der au scaffolding de son impl\u00e9mentation en appuyant sur Alt-Entr\u00e9e<\/strong> (\u2325Option<\/strong>\u2013Retour<\/strong>) et en ex\u00e9cutant l’action sugg\u00e9r\u00e9e\u00a0:<\/p>\n
\"\"<\/figure>\n
Suite \u00e0 cette action, RustRover g\u00e9n\u00e8re le mod\u00e8le d’impl\u00e9mentation de la m\u00e9thode en prenant en compte les informations contextuelles concernant les types\u00a0:<\/p>\n
impl Info {\n\u00a0\u00a0\u00a0pub(crate) fn summary(&self) -> String {\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0todo!()\n\u00a0\u00a0\u00a0}\n}<\/pre>\n
L’ex\u00e9cution de ce code r\u00e9sulte en une erreur d’ex\u00e9cution, mais au moins le compilateur n’y trouve rien \u00e0 redire.<\/p>\n
Erreur fr\u00e9quente n\u00b0\u00a02\u00a0: E0308 (Le type attendu ne correspondait pas au type re\u00e7u<\/em>)<\/h2>\n
Imaginez que vous utilisiez une expression de type A<\/code> dans un contexte o\u00f9 une valeur de type B<\/code> est attendue. Ici, la notion de \u00ab\u00a0contexte\u00a0\u00bb peut d\u00e9signer plusieurs choses, comme un param\u00e8tre de fonction sur un site d’appel, une d\u00e9claration de variable ou une instruction\/expression de contr\u00f4le du flux. 30\u00a0% des utilisateurs de RustRover ont d\u00e9j\u00e0 \u00e9t\u00e9 dans cette situation.<\/p>\n
D’un point de vue conceptuel, deux choix s’offrent \u00e0 nous dans ce cas : modifier une valeur ou modifier le contexte. La modification d’une valeur peut impliquer le typage, le r\u00e9f\u00e9rencement\/d\u00e9r\u00e9f\u00e9rencement, l’appel d’une m\u00e9thode de transformation ou son remplacement par quelque chose d’autre. On ne peut pas toujours agir sur le contexte, mais il est parfois possible de modifier le type attendu pour qu’il corresponde au type re\u00e7u.<\/p>\n
RustRover prend en charge les deux modes op\u00e9ratoires en fournissant plusieurs correctifs rapides, par exemple\u00a0:<\/p>\n
\"\"<\/figure>\n
Notez la deuxi\u00e8me suggestion dans la liste\u00a0: dans ce cas, RustRover a sugg\u00e9r\u00e9 une transformation assez sophistiqu\u00e9e d’une valeur qui convient au compilateur. Suivre la premi\u00e8re suggestion corrigerait le contexte, \u00e0 savoir la d\u00e9finition de la fonction.\u00a0<\/p>\n
Erreur fr\u00e9quente n\u00b0\u00a01\u00a0: E0277 (Vous avez essay\u00e9 d’utiliser un type qui n’impl\u00e9mente pas de trait \u00e0 un endroit o\u00f9 un trait est attendu<\/em>)<\/h2>\n
Enfin, nous arrivons \u00e0 la 1\u00e8re place du classement\u00a0! L’erreur du compilateur Rust la plus fr\u00e9quemment rencontr\u00e9e dans RustRover est E0277. 32\u00a0% des utilisateurs de RustRover ont fait l’exp\u00e9rience de cette situation cauchemardesque m\u00ealant types et traits. L’explication officielle<\/a> fait un bon travail en fournissant des exemples et des explications des correctifs possibles. Ici, nous allons observer le comportement de RustRover.<\/p>\n
Voici ma fonctionnalit\u00e9 de RustRover pr\u00e9f\u00e9r\u00e9e lorsqu’il s’agit de ce genre d’erreur\u00a0:\u00a0<\/p>\n
\"\"<\/figure>\n
Le compilateur renvoie le message d’erreur suivant\u00a0:<\/p>\n
error[E0277]: `Info` doesn't implement `std::fmt::Display`<\/pre>\n
Bien s\u00fbr, l’impl\u00e9mentation du traitDisplay<\/code> est un choix possible, et RustRover peut aider pour le scaffolding d’une impl\u00e9mentation. Mais dans ce cas, je pr\u00e9f\u00e8re appliquer la premi\u00e8re suggestion, qui comprend deux \u00e9tapes simultan\u00e9es\u00a0:<\/p>\n