Lorsqu’un utilisateur ayant donn\u00e9 son consentement lance la commande Cargo Build depuis l’IDE (par exemple, en d\u00e9clenchant une configuration Run qui n\u00e9cessite la compilation d’un projet) et que le compilateur Rust signale une erreur, nous enregistrons un code d’erreur<\/a>. Cela n’inclut pas tous<\/em> les probl\u00e8mes qui surviennent pendant que les utilisateurs \u00e9crivent leur code, mais seulement ceux qui persistent apr\u00e8s qu’ils aient cr\u00e9\u00e9 leur projet. Les erreurs interm\u00e9diaires peuvent souvent \u00eatre corrig\u00e9es \u00e0 l’aide des inspections et des correctifs rapides fournis par l’IDE.\u00a0<\/p>\n Nous avons collect\u00e9 les codes d’erreur des utilisateurs de RustRover et avons class\u00e9 les erreurs en fonction de leur fr\u00e9quence. Cet article porte sur les erreurs figurant de la 10\u00e8me \u00e0 la 6\u00e8me place et le prochain r\u00e9v\u00e9lera les cinq erreurs les plus fr\u00e9quentes. Nous allons examiner les causes de ces erreurs en utilisant des exemples simples et voir quels sont les moyens de les corriger.<\/p>\n Rust fait une distinction stricte entre les sites de d\u00e9claration de type et les utilisations de nom de type. Chaque nom de type (y compris les types g\u00e9n\u00e9riques) doit \u00eatre d\u00e9clar\u00e9 quelque part et \u00eatre disponible dans la port\u00e9e dans laquelle il est utilis\u00e9. Lorsque le compilateur rencontre une utilisation de nom de type et n’a pas d’information sur son site de d\u00e9claration, il \u00e9met l’erreur E0412. Environ 12\u00a0% des utilisateurs de RustRover ont d\u00e9j\u00e0 fait l’exp\u00e9rience de cette erreur.<\/p>\n Imaginons que vous ayez saisi Une erreur E0412 peut se produire dans d’autres situations, notamment :<\/p>\n Pour r\u00e9soudre le probl\u00e8me, vous pouvez fournir une d\u00e9claration de type (d\u00e9clarer un struct ou introduire un nom de type g\u00e9n\u00e9rique correctement) ou amener le type dans une port\u00e9e (via la clause Bien que RustRover connaisse cette erreur et fournisse plusieurs correctifs, 13\u00a0% des utilisateurs la laissent passer et omettent de la corriger avant la cr\u00e9ation de leurs projets.<\/p>\n L’intitul\u00e9 de cette erreur est assez explicite\u00a0: une fonction est d\u00e9clar\u00e9e dans la port\u00e9e actuelle ou import\u00e9e 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 \u00e0 celles du compilateur Rust\u00a0:<\/p>\n Si on a l’habitude de programmer avec un autre langage, on pourrait \u00eatre tent\u00e9 de fournir un deuxi\u00e8me argument, en oubliant qu’en Rust, cette m\u00e9thode n’en prend qu’un seul. RustRover et le compilateur Rust nous invitent donc \u00e0 supprimer le second argument. Il est appr\u00e9ciable de b\u00e9n\u00e9ficier de cette suggestion de la part de l’IDE avant d’avoir cr\u00e9\u00e9 le projet. Pr\u00eatez attention aux lignes de soulignement rouges ondul\u00e9es dans votre code : g\u00e9n\u00e9ralement, elles sont l\u00e0 pour une bonne raison !<\/p>\n La situation devient plus int\u00e9ressante si la fonction que nous appelons est d\u00e9finie dans notre propre code. Supposons que nous continuons de travailler sur le m\u00eame exemple de code\u00a0:<\/p>\n Dans ce cas, RustRover sugg\u00e8re comme premi\u00e8re solution d’ajouter un param\u00e8tre \u00e0 la fonction, ce qui peut faire sens. Le compilateur Rust insiste quant \u00e0 lui pour le supprimer. Cette divergence a une explication logique. Le travail du compilateur consiste \u00e0 s’assurer que le programme est correct, et le moyen le plus facile d’y parvenir consiste \u00e0 \u00e9liminer l’argument suppl\u00e9mentaire sur le site de l’appel. En revanche, la mission de l’IDE est de vous accompagner vers la r\u00e9alisation de votre objectif. Si vous avez saisi cet argument pour votre fonction, RustRover consid\u00e8re qu’il est probable que cela soit volontaire et tente donc de vous aider \u00e0 terminer ce que vous avez commenc\u00e9.<\/p>\n Parfois le compilateur est perdu\u00a0: il ne trouve pas quel est le type requis pour une variable et ne peut que sugg\u00e9rer d’ajouter une annotation manuellement. Si vous avez d\u00e9j\u00e0 rencontr\u00e9 cette erreur, bienvenue au club : 13,5\u00a0% des utilisateurs de RustRover y ont d\u00e9j\u00e0 \u00e9t\u00e9 confront\u00e9s.<\/p>\n La source principale des erreurs telles que E0282 est la g\u00e9n\u00e9ricit\u00e9. De nombreuses fonctions de biblioth\u00e8ques utilisent des param\u00e8tres de type g\u00e9n\u00e9rique, mais le compilateur doit instancier ces param\u00e8tres en type concret, ce qui est source de confusion pour lui. Prenons l’exemple\u00a0suivant\u00a0:<\/p>\n Ici nous devons collecter des nombres \u00e0 partir d’une cha\u00eene dans un conteneur. Malheureusement, le compilateur ne peut pas d\u00e9terminer le type des nombres ou le genre de conteneur dont il s’agit.<\/p>\n Le compilateur sugg\u00e8re la sp\u00e9cification du type de conteneur en premier. Cependant, si nous appliquons ce correctif, nous obtiendrons de nouveau le m\u00eame genre d’erreur, mais concernant Il existe plusieurs fa\u00e7ons de corriger le probl\u00e8me, car une annotation de type peut \u00eatre ajout\u00e9e \u00e0 diff\u00e9rents endroits. Nous pouvons sp\u00e9cifier le type concret du vecteur Ou nous pouvons mentionner le m\u00eame type lors de l’appel de Enfin, nous pouvons mentionner diff\u00e9rents types \u00e0 diff\u00e9rents endroits\u00a0:<\/p>\n Cette erreur est facile \u00e0 corriger\u00a0: il suffit de sp\u00e9cifier le type ou les types que vous voulez.<\/p>\n RustRover fournit de nombreuses fonctionnalit\u00e9s de saisie semi-automatique. Commen\u00e7ons par exemple en introduisant une expression r\u00e9guli\u00e8re dans notre code\u00a0:<\/p>\n Si vous choisissez la premi\u00e8re suggestion, deux autres choses vont se produire en plus de la saisie semi-automatique elle-m\u00eame\u00a0:<\/p>\n Lorsque vous ajoutez des clauses d’utilisation comme cela, les importations sont \u00e9crites automatiquement et correctement. Mais il faut parfois \u00e9crire les importations manuellement et c’est l\u00e0 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\u00e9sence d’une clause Parfois, RustRover peut nous aider \u00e0 \u00e9viter cette erreur. S’il a connaissance de la crate que nous tentons d’importer, il sugg\u00e8re l’ajout d’une d\u00e9pendance lorsque vous collez du code depuis des sources externes ou fournit une assistance via les correctifs rapides suivants :<\/p>\n L’ajout de la d\u00e9pendance correspondante \u00e0 Cargo.toml<\/kbd> corrige l’erreur imm\u00e9diatement. Une fois que la crate est disponible, il est plus s\u00fbr d’utiliser la saisie semi-automatique pour les autres composants du chemin dans les clauses Il peut \u00e9galement y avoir des probl\u00e8mes avec les noms de chemin sp\u00e9ciaux tels que Point int\u00e9ressant\u00a0: les probl\u00e8mes li\u00e9s \u00e0 la possession\u00a0! 17\u00a0% des utilisateurs de RustRover ont d\u00e9j\u00e0 rencontr\u00e9 cette erreur. L’explication officielle<\/a> est tr\u00e8s d\u00e9taill\u00e9e et donne de nombreux exemples. Malheureusement, RustRover n’est pas d’une grande aide dans ce cas. Si un linter externe<\/a> est d\u00e9sactiv\u00e9, le m\u00e9canisme interne de RustRover ne voit aucun probl\u00e8me dans le code suivant\u00a0:<\/p>\n Ce code d’aspect anodin serait parfaitement l\u00e9gitime dans certains autres langages de programmation. Nous avons un vecteur et voulons calculer la somme de ses \u00e9l\u00e9ments. Si vous travaillez habituellement avec C et que vous ne connaissez pas les astuces de programmation li\u00e9es aux it\u00e9rateurs, vous \u00e9cririez plut\u00f4t une boucle Eh bien pas ce n’est pas le cas avec Rust, \u00e0 cause des r\u00e8gles de la possession propres au langage.\u00a0<\/p>\n Le probl\u00e8me est que la source de donn\u00e9es dans la boucle Le correctif propos\u00e9 par le navigateur\u00a0est simple : it\u00e9rer sur En g\u00e9n\u00e9ral, il est utile de conserver constamment une trace des r\u00e8gles de possession des valeurs. Le d\u00e9placement et l’emprunt de valeurs sont des concepts fondamentaux de Rust. Il est important pour les n\u00e9ophytes d’assimiler ces concepts d\u00e8s le d\u00e9but.<\/p>\n Dans ce premier article, nous avons pass\u00e9 en revue certaines des erreurs du compilateur Rust les plus fr\u00e9quentes en nous basant sur les donn\u00e9es d’utilisation de RustRover. Dans le prochain article, nous verrons les 5 erreurs les plus fr\u00e9quentes et tenterons de r\u00e9pondre \u00e0 une question que se posent tous les d\u00e9veloppeurs Rust : \u00ab Quelle partie de Rust cause le plus de probl\u00e8mes ? \u00bb.<\/p>\n\n\n Auteur de l’article original en anglais<\/em> :<\/p>\n\n\n Erreur fr\u00e9quente n\u00b0\u00a010\u00a0: E0412 (Un nom de type utilis\u00e9 n’est pas dans la port\u00e9e)<\/em><\/h2>\n
i42<\/code> au lieu de i32<\/code>. RustRover d\u00e9tecte ce probl\u00e8me et met en \u00e9vidence le nom de type inconnu. Le compilateur donne plus de d\u00e9tails et propose un correctif qui peut \u00eatre facilement appliqu\u00e9 en cliquant sur le bouton Apply fix<\/em> dans la sortie du compilateur\u00a0:<\/p>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2023\/12\/image-16.png\")
<\/figure>\n\n
use<\/code>). L’explication officielle de l’erreur E0412<\/a> donne plus d’exemples.<\/p>\nErreur fr\u00e9quente n\u00b0\u00a09\u00a0: E0061 (Un nombre non valide d’arguments a \u00e9t\u00e9 pass\u00e9 lors de l’appel d’une fonction<\/em>)<\/h2>\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2023\/12\/image-17.png\")
<\/figure>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2023\/12\/image-18.png\")
<\/figure>\nErreur fr\u00e9quente n\u00b0\u00a08\u00a0: E0282 (Le compilateur n’a pas pu d\u00e9duire un type et a demand\u00e9 une annotation de type<\/em>)<\/h2>\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2023\/12\/image-19.png\")
<\/figure>\nstr::parse<\/code> cette fois. collect<\/code> et parse<\/code> sont des m\u00e9thodes g\u00e9n\u00e9riques, mais le compilateur a besoin de conna\u00eetre le type pr\u00e9cis afin de compiler le code qui les utilise. Veuillez noter que RustRover ne met pas les erreurs en \u00e9vidence, car nous travaillons encore au perfectionnement de sa fonctionnalit\u00e9 de v\u00e9rification de type.<\/p>\nnumbers<\/code>\u00a0:<\/p>\nlet numbers: Vec = \"1\u00a0 5 \u00a0 \u00a0 6 \u00a0 3\"<\/pre>\n
collect<\/code>\u00a0:<\/p>\n .collect::<Vec>();<\/pre>\n
let numbers = \"1\u00a0 5 \u00a0 \u00a0 6 \u00a0 3\"\n\u00a0\u00a0\u00a0.split_whitespace()\n\u00a0\u00a0\u00a0.map(str::parse::)\n\u00a0\u00a0\u00a0.map(Result::unwrap)\n\u00a0\u00a0\u00a0.collect::<Vec>();<\/pre>\n
Erreur fr\u00e9quente n\u00b0\u00a07\u00a0: E0432 (Une importation n’a pas \u00e9t\u00e9 r\u00e9solue<\/em>)<\/h2>\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2023\/12\/image-20.png\")
<\/figure>\n\n
regex<\/code> sera ajout\u00e9e \u00e0 votre fichier Cargo.toml<\/kbd>.<\/li>\nuse regex::Regex;<\/code> sera ajout\u00e9e en haut du fichier.<\/li>\n<\/ul>\nuse<\/code> erron\u00e9e dans le code apr\u00e8s l’avoir copi\u00e9e\/coll\u00e9e \u00e0 partir un autre endroit. La premi\u00e8re suggestion est de toujours v\u00e9rifier les d\u00e9pendances et les noms.<\/p>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2023\/12\/image-21.png\")
<\/figure>\nuse<\/code>, afin d’\u00e9viter la survenance de nouveaux probl\u00e8mes avec les noms. Rappelez-vous aussi que la disponibilit\u00e9 de certains noms peut d\u00e9pendre des fonctionnalit\u00e9s de la crate qui sont activ\u00e9es.<\/p>\nsuper<\/code> ou crate<\/code>, notamment parce qu’ils sont trait\u00e9s diff\u00e9remment dans les diff\u00e9rentes versions de Rust. Vous trouverez plus d’informations \u00e0 ce sujet dans l’explication officielle<\/a>.<\/p>\nErreur fr\u00e9quente n\u00b0\u00a06\u00a0: E0382 (Une variable a \u00e9t\u00e9 utilis\u00e9e apr\u00e8s que son contenu ait \u00e9t\u00e9 d\u00e9plac\u00e9<\/em>)<\/h2>\n
fn main() {\n\u00a0\u00a0\u00a0let vec = vec![1, 2, 3, 4, 5];\n\u00a0\u00a0\u00a0let mut sum = 0;\n\u00a0\u00a0\u00a0for v in vec {\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0sum += v;\n\u00a0\u00a0\u00a0}\n\u00a0\u00a0\u00a0println!(\"Sum of {vec:?} elements is {sum}\");\n}<\/pre>\nfor<\/code> traditionnelle \u00e0 la place. Une fois les \u00e9l\u00e9ments ajout\u00e9s, il n’y aurait alors plus qu’\u00e0 imprimer le vecteur et le r\u00e9sultat des calculs. Exact ?<\/p>\nfor<\/code> est \u00e9tendue \u00e0 l’appel into_iter()<\/code>, qui prend alors possession de l’ensemble du vecteur. Par cons\u00e9quent, lorsque nous tenterons ensuite d’acc\u00e9der aux \u00e9l\u00e9ments du vecteur dans println!<\/code>, le compilateur indiquera qu’il a \u00e9t\u00e9 d\u00e9plac\u00e9.<\/p>\n&vec<\/code> pour \u00e9viter de le d\u00e9placer<\/em> dans la boucle, puis l’emprunter<\/em> .<\/p>\nR\u00e9sum\u00e9<\/h2>\n
![\"\"](\"https:\/\/secure.gravatar.com\/avatar\/?s=200&r=g\")