From aa96a9ab77d8ac633d18f476c5c751d33319b6e7 Mon Sep 17 00:00:00 2001 From: Jimskapt Date: Sat, 22 Jan 2022 12:46:32 +0100 Subject: [PATCH] =?UTF-8?q?=F0=9F=8E=A8=20markdownlint.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .vscode/settings.json | 3 +- FRENCH/src/ch06-02-match.md | 1 + FRENCH/src/ch11-02-running-tests.md | 11 ++--- FRENCH/src/ch11-03-test-organization.md | 18 ++++----- ...improving-error-handling-and-modularity.md | 40 +++++++++---------- ...2-04-testing-the-librarys-functionality.md | 18 +++++---- ...2-05-working-with-environment-variables.md | 18 ++++----- ...-06-writing-to-stderr-instead-of-stdout.md | 6 +-- FRENCH/src/ch13-02-iterators.md | 5 +-- FRENCH/src/ch13-04-performance.md | 4 +- FRENCH/src/ch14-02-publishing-to-crates-io.md | 16 ++++---- FRENCH/src/ch14-03-cargo-workspaces.md | 17 ++++---- FRENCH/src/ch14-04-installing-binaries.md | 11 ++--- FRENCH/src/ch15-00-smart-pointers.md | 3 +- FRENCH/src/ch15-02-deref.md | 20 +++++----- FRENCH/src/ch15-04-rc.md | 1 - FRENCH/src/ch15-05-interior-mutability.md | 1 - FRENCH/src/ch16-03-shared-state.md | 8 ++-- FRENCH/src/ch19-01-unsafe-rust.md | 19 ++++----- .../ch20-03-graceful-shutdown-and-cleanup.md | 1 - 20 files changed, 113 insertions(+), 108 deletions(-) diff --git a/.vscode/settings.json b/.vscode/settings.json index 76998f52a8..d314f2eaa6 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -12,8 +12,9 @@ "MD014": false, "MD026": false, "MD033": { - "allowed_elements": ["img", "span", "sup", "a"] + "allowed_elements": ["img", "span", "sup", "a", "div"] }, + "MD034": false, "MD041": false } } diff --git a/FRENCH/src/ch06-02-match.md b/FRENCH/src/ch06-02-match.md index 349bb15969..2831f46057 100644 --- a/FRENCH/src/ch06-02-match.md +++ b/FRENCH/src/ch06-02-match.md @@ -4,6 +4,7 @@ --> + ## La structure de contrôle de flux `match` Nous avons réglé le nombre de tâches à `1`, ce qui indique au programme de ne -pas utiliser le parallélisme. Exécuter ces tests en n'effectuant qu'une seule tâche -à la fois va prendre plus de temps que de les lancer en parallèle, mais cela assure que -les tests ne vont pas s'influencer mutuellement s'ils partagent le même état. +pas utiliser le parallélisme. Exécuter ces tests en n'effectuant qu'une seule +tâche à la fois va prendre plus de temps que de les lancer en parallèle, mais +cela assure que les tests ne vont pas s'influencer mutuellement s'ils partagent +le même état. , les éléments dans les modules enfants peuvent utiliser les éléments dans leurs modules parents. Dans ce test, nous importons dans la portée tous les éléments -du parent du module `test` grâce à `use super::*;`, permettant ensuite au test de -faire appel à `addition_interne`. Si vous pensez qu'une fonction privée ne doit -pas être testée, il n'y a rien qui vous y force avec Rust. +du parent du module `test` grâce à `use super::*;`, permettant ensuite au test +de faire appel à `addition_interne`. Si vous pensez qu'une fonction privée ne +doit pas être testée, il n'y a rien qui vous y force avec Rust. -Nous créons un dossier *tests* au niveau le plus haut de notre dossier -projet, juste à côté de *src*. Cargo sait qu'il doit rechercher les fichiers de -test d'intégration dans ce dossier. Nous pouvons ensuite construire autant de +Nous créons un dossier *tests* au niveau le plus haut de notre dossier projet, +juste à côté de *src*. Cargo sait qu'il doit rechercher les fichiers de test +d'intégration dans ce dossier. Nous pouvons ensuite construire autant de fichiers de test que nous le souhaitons dans ce dossier, et Cargo va compiler chacun de ces fichiers comme une crate individuelle. @@ -315,9 +315,9 @@ Listing 11-12) and then a summary line for the unit tests. Les trois sections de la sortie concernent les tests unitaires, les tests d'intégration et les tests de documentation. La première section relative aux -tests unitaires est la même que celle que nous avons déjà vue : une ligne pour chaque test -unitaire (celui qui s'appelle `interne` que nous avons inséré dans l'encart -11-12) suivie d'une ligne de résumé des tests unitaires. +tests unitaires est la même que celle que nous avons déjà vue : une ligne pour +chaque test unitaire (celui qui s'appelle `interne` que nous avons inséré dans +l'encart 11-12) suivie d'une ligne de résumé des tests unitaires. , vous allez apprendre à utiliser des > méthodes plus efficaces dans ce genre de situation. Mais pour le moment, ce > n'est pas un problème de copier quelques chaînes de caractères pour continuer -> à progresser car vous allez le faire une seule fois et les chaînes -> de caractères `nom_fichier` et `recherche` sont très courtes. Il est plus important -> d'avoir un programme -> fonctionnel qui n'est pas très optimisé plutôt que d'essayer d'optimiser à -> outrance le code dès sa première écriture. Plus vous deviendrez expérimenté -> en Rust, plus il sera facile de commencer par la solution la plus -> performante, mais pour le moment, il est parfaitement acceptable de faire -> appel à `clone`. +> à progresser car vous allez le faire une seule fois et les chaînes de +> caractères `nom_fichier` et `recherche` sont très courtes. Il est plus +> important d'avoir un programme fonctionnel qui n'est pas très optimisé plutôt +> que d'essayer d'optimiser à outrance le code dès sa première écriture. Plus +> vous deviendrez expérimenté en Rust, plus il sera facile de commencer par la +> solution la plus performante, mais pour le moment, il est parfaitement +> acceptable de faire appel à `clone`. nous avions vu que le paramètre de durée de vie indique quelle durée de vie d'argument est connectée à la durée de vie de la valeur de retour. Dans notre cas, nous indiquons que le -vecteur retourné devrait contenir des slices de chaînes de caractères qui proviennent -des slices de l'argument `contenu` (et pas de l'argument `recherche`). +vecteur retourné devrait contenir des slices de chaînes de caractères qui +proviennent des slices de l'argument `contenu` (et pas de l'argument +`recherche`). Très bien ! Nous avons construit notre propre mini-version d'un outil classique -et nous avons beaucoup appris sur la façon de structurer nos applications. Nous en avons aussi -appris un peu sur les entrées et sorties des fichiers, les durées de vie, les -tests et l'interprétation de la ligne de commande. +et nous avons beaucoup appris sur la façon de structurer nos applications. Nous +en avons aussi appris un peu sur les entrées et sorties des fichiers, les +durées de vie, les tests et l'interprétation de la ligne de commande. -Nous devrions trouver cette fois-ci également toutes les lignes qui contiennent “to” écrit avec certaines lettres en majuscule: +Nous devrions trouver cette fois-ci également toutes les lignes qui contiennent +“to” écrit avec certaines lettres en majuscule: -Après avoir changé `println!` en `eprintln!`, exécutons à nouveau le programme +Après avoir changé `println!` en `eprintln!`, exécutons à nouveau le programme de la même manière, sans aucun argument et en redirigeant la sortie standard avec `>` : diff --git a/FRENCH/src/ch13-02-iterators.md b/FRENCH/src/ch13-02-iterators.md index 3c2232f463..2738deb205 100644 --- a/FRENCH/src/ch13-02-iterators.md +++ b/FRENCH/src/ch13-02-iterators.md @@ -652,8 +652,8 @@ always starting new instances with a value of 0 in the `count` field. La structure `Compteur` a un champ `compteur`. Ce champ contient une valeur `u32` qui gardera la trace de l'endroit où nous sommes dans le processus d'itération de 1 à 5. Le champ `compteur` est privé car nous voulons que ce soit -l'implémentation de `Compteur` qui gère sa valeur. La fonction `new` impose -de toujours démarrer de nouvelles instances avec une valeur de 0 pour le champ +l'implémentation de `Compteur` qui gère sa valeur. La fonction `new` impose de +toujours démarrer de nouvelles instances avec une valeur de 0 pour le champ `compteur`. - Encart 13-23 : utilisation d'une gamme de méthodes du trait `Iterator` sur notre itérateur `Compteur` diff --git a/FRENCH/src/ch13-04-performance.md b/FRENCH/src/ch13-04-performance.md index 50d1b70c8b..49f099f298 100644 --- a/FRENCH/src/ch13-04-performance.md +++ b/FRENCH/src/ch13-04-performance.md @@ -71,8 +71,8 @@ s'agisse d'une abstraction de haut niveau, sont compilés à peu près comme si vous aviez écrit vous-même le code un niveau plus bas. Les itérateurs sont l'une des abstractions à *coût zéro* de Rust, c'est-à-dire que l'utilisation de l'abstraction n'impose aucun surcoût lors de l'exécution. C'est la même notion -que celle que Bjarne Stroustrup, le concepteur et développeur original de C++, définit -en tant que *coût zéro* dans “Foundations of C++” (2012) : +que celle que Bjarne Stroustrup, le concepteur et développeur original de C++, +définit en tant que *coût zéro* dans “Foundations of C++” (2012) : Notez que les types `CouleurPrimaire` et `CouleurSecondaire` ne sont pas listés -sur la page d'accueil, pas plus que la fonction `mixer`. Nous devons cliquer sur `types` -et `utilitaires` pour les voir. +sur la page d'accueil, pas plus que la fonction `mixer`. Nous devons cliquer +sur `types` et `utilitaires` pour les voir. -Une fois le nom unique, la version, la description et la licence -ajoutés, le fichier *Cargo.toml* de ce projet qui est prêt à être publié devrait -ressembler à ceci : +Une fois le nom unique, la version, la description et la licence ajoutés, le +fichier *Cargo.toml* de ce projet qui est prêt à être publié devrait ressembler +à ceci : Pour corriger cela, modifiez le fichier *Cargo.toml* pour le paquet -`additioneur` et indiquez que `rand` est une dépendance de cette crate aussi. La compilation du -paquet `additioneur` va rajouter `rand` à la liste des dépendances pour -`additioneur` dans *Cargo.lock*, mais aucune copie supplémentaire de `rand` ne sera -téléchargée. Cargo s'est assuré que toutes les crates de chaque paquet de -l'espace de travail qui utilise le paquet `rand` seraient de la même version. -Utiliser la même version de `rand` dans les espaces de travail économise de -l'espace car nous n'avons pas à multiplier les copies, ni à nous assurer que les -crates dans l'espace de travail sont compatibles les unes avec les autres. +`additioneur` et indiquez que `rand` est une dépendance de cette crate aussi. +La compilation du paquet `additioneur` va rajouter `rand` à la liste des +dépendances pour `additioneur` dans *Cargo.lock*, mais aucune copie +supplémentaire de `rand` ne sera téléchargée. Cargo s'est assuré que toutes les +crates de chaque paquet de l'espace de travail qui utilise le paquet `rand` +seraient de la même version. Utiliser la même version de `rand` dans les +espaces de travail économise de l'espace car nous n'avons pas à multiplier les +copies, ni à nous assurer que les crates dans l'espace de travail sont +compatibles les unes avec les autres. La commande `cargo install` vous permet d'installer et utiliser des crates de -binaires localement. Cela n'est pas conçu pour remplacer les paquets systèmes ; +binaires localement. Cela n'est pas conçu pour remplacer les paquets systèmes ; c'est plutôt un moyen pratique pour les développeurs Rust d'installer des outils que les autres ont partagé sur [crates.io](https://crates.io/). Notez que vous ne pouvez installer que des paquets qui ont des destinations binaires. Une *destination binaire* est le programme exécutable qui est créé si la crate a un fichier *src/main.rs* ou un autre fichier désigné comme binaire, par opposition -à une destination de bibliothèque qui n'est pas exécutable en tant que telle mais -qu'il est possible d'intégrer à d'autres programmes. Habituellement, l'information permettant -de savoir si une crate est une bibliothèque, possède plutôt une destination binaire ou les deux -à la fois figure dans le fichier *README*. +à une destination de bibliothèque qui n'est pas exécutable en tant que telle +mais qu'il est possible d'intégrer à d'autres programmes. Habituellement, +l'information permettant de savoir si une crate est une bibliothèque, possède +plutôt une destination binaire ou les deux à la fois figure dans le +fichier *README*. Le troisième cas est plus ardu : Rust va aussi procéder à une extrapolation de -déréférencement d'une référence mutable vers une référence immuable. Mais -l'inverse n'est *pas* possible: une extrapolation de déréférencement d'une +déréférencement d'une référence mutable vers une référence immuable. Mais +l'inverse n'est *pas* possible: une extrapolation de déréférencement d'une valeur immuable ne donnera jamais une référence mutable. A cause des règles -d'emprunt, si vous avez une référence mutable, cette référence mutable doit être -la seule référence vers cette donnée (autrement, le programme ne peut pas être -compilé). Convertir une référence mutable vers une référence immuable ne va -jamais casser les règles d'emprunt. Convertir une référence immuable vers une -référence mutable nécessite que la référence immuable initiale soit la seule -référence immuable vers cette donnée, mais les règles d'emprunt n'empêchent pas -cela. Ainsi, Rust ne peut pas déduire que la conversion d'une référence immuable -vers une référence mutable soit possible. +d'emprunt, si vous avez une référence mutable, cette référence mutable doit +être la seule référence vers cette donnée (autrement, le programme ne peut pas +être compilé). Convertir une référence mutable vers une référence immuable ne +va jamais casser les règles d'emprunt. Convertir une référence immuable vers +une référence mutable nécessite que la référence immuable initiale soit la +seule référence immuable vers cette donnée, mais les règles d'emprunt +n'empêchent pas cela. Ainsi, Rust ne peut pas déduire que la conversion d'une +référence immuable vers une référence mutable soit possible. diff --git a/FRENCH/src/ch15-04-rc.md b/FRENCH/src/ch15-04-rc.md index f79534b773..c6660bf402 100644 --- a/FRENCH/src/ch15-04-rc.md +++ b/FRENCH/src/ch15-04-rc.md @@ -150,7 +150,6 @@ Si nous essayons d'implémenter ce scénario en utilisant les définitions de {{#rustdoc_include ../listings/ch15-smart-pointers/listing-15-17/src/main.rs}} ``` - -La gestion des mutex peut devenir incroyablement compliquée, c'est pourquoi tant de -personnes sont partisanes des canaux. Cependant, grâce au système de type de -Rust et aux règles de possession, vous ne pouvez pas vous tromper dans le -verrouillage et déverrouillage. +La gestion des mutex peut devenir incroyablement compliquée, c'est pourquoi +tant de personnes sont partisanes des canaux. Cependant, grâce au système de +type de Rust et aux règles de possession, vous ne pouvez pas vous tromper dans +le verrouillage et déverrouillage.  : -le compilateur implémente automatiquement ces traits si nos types sont -entièrement composés des types `Send` et `Sync`. Si nous implémentions un type -qui contenait un type qui n'était pas `Send` ou `Sync`, comme des pointeurs -bruts, et nous souhaitions marquer ce type comme étant `Send` ou `Sync`, nous -aurions dû utiliser `unsafe`. Rust ne peut pas vérifier que notre type respecte -les garanties pour que ce type puisse être envoyé en toute sécurité entre des -tâches ou qu'il puisse être utilisé par plusieurs tâches ; toutefois, nous avons -besoin de faire ces vérifications manuellement et les signaler avec `unsafe`. +[chapitre 16][extensible-concurrency-with-the-sync-and-send-traits] : le compilateur implémente automatiquement ces traits si nos types +sont entièrement composés des types `Send` et `Sync`. Si nous implémentions un +type qui contenait un type qui n'était pas `Send` ou `Sync`, comme des +pointeurs bruts, et nous souhaitions marquer ce type comme étant `Send` ou +`Sync`, nous aurions dû utiliser `unsafe`. Rust ne peut pas vérifier que notre +type respecte les garanties pour que ce type puisse être envoyé en toute +sécurité entre des tâches ou qu'il puisse être utilisé par plusieurs tâches ; +toutefois, nous avons besoin de faire ces vérifications manuellement et les +signaler avec `unsafe`.