Mozilla annonce la disponibilité de Rust 1.16
Qui s'accompagne de la sous-commande cargo check

Le , par Stéphane le calme, Chroniqueur Actualités
L’équipe responsable du développement de Rust a annoncé la disponibilité de la version stable 1.16. L’un des ajouts majeurs apportés au langage de programmation est la sous-commande cargo check laquelle, selon l’équipe, devrait vous aider à accélérer votre flux de travail dans bien des cas.

Que fait-elle exactement ? Avant d’y parvenir, il faut d’abord s’intéresser à la façon dont rustc compile votre code. Il existe de nombreuses étapes distinctes par lesquelles le compilateur passe entre votre code source et la production du binaire final. Pour observer ces étapes, et surtout combien de temps et de mémoire elles prennent, vous pouvez lancer la commande -Z time-passes à un compilateur nightly.

rustc .\hello.rs -Z time-passes
time: 0.003; rss: 16MB parsing
time: 0.000; rss: 16MB recursion limit
time: 0.000; rss: 16MB crate injection
time: 0.000; rss: 16MB plugin loading
time: 0.000; rss: 16MB plugin registration
time: 0.049; rss: 34MB expansion
<snip>

Comme vous pouvez le constater avec cet exemple, il y a plusieurs étapes. Cependant, nous pouvons les regrouper en deux grandes catégories :
  • tout d'abord, rustc effectue toutes ses vérifications de sécurité, il s'assure que votre syntaxe est correcte, etc. ;
  • ensuite, une fois qu'il a terminé ses routines de vérification, il produit le code binaire réel que vous finissez par exécuter.

Il s’avère que cette seconde grande étape prend beaucoup de temps qui n'est pas souvent nécessaire. Autrement dit, lorsque vous travaillez sur un code Rust, de nombreux développeurs vont procéder comme suit :
  1. Écrire une portion de code ;
  2. Exécuter cargo build pour s'assurer qu'il n’y a pas d’erreurs de compilation ;
  3. Répéter les étapes 1 et 2 si nécessaire ;
  4. Exécutez cargo test pour s'assurer qu’il n’y pas d’erreurs dans les tests ;
  5. Retour à l’étape numéro 1.

En réalité, une fois rendu à l’étape 2, il n’est pas vraiment question de lancer l’exécution de votre code : il s’agit d’avoir un feedback du compilateur, mais pas dans l’optique d’exécuter le binaire. C’est dans ce cas d’utilisation que cargo check intervient : il exécute toutes les vérifications du compilateur, mais ne produit pas le binaire final.

Alors concrètement de quel pourcentage de vitesse les développeurs vont-ils bénéficier ? Les ingénieurs indiquent que, comme c'est le cas avec les questions de performance, la réponse est « ça dépend ». Toutefois, ils ont fourni un benchmark permettant de comparer des gains de vitesse sur différentes catégories.

Fonctionnalités de cargo

En plus de cargo check, Cargo et crates.io ont été retravaillés. Par exemple, cargo build et cargo docsupportent désormais le flag --all pour construire et documenter tous les “crate” dans votre espace de travail en une commande.

Pour rappel, Rust a deux termes distincts qui se rapportent au système de module : 'crate' et 'module'. Un crate est synonyme d'une « bibliothèque » ou d'un « paquet » dans d'autres langages. Par conséquent, "Cargo”, en tant que nom de l'outil de gestion de paquets de Rust, permet de diffuser les “crate” à d’autres avec Cargo. Les “crate” peuvent produire un exécutable ou une bibliothèque, selon le projet.

Autres améliorations

Afin de supporter cargo check, rustc fournit désormais un nouveau type de fichier : .rmeta. Ce fichier contient uniquement des métadonnées sur un “crate” en particulier. cargo check en a besoin pour vos dépendances afin de laisser le compilateur vérifier par exemple les types.

Source : blog Rust


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de joublie joublie - Membre habitué https://www.developpez.com
le 18/03/2017 à 13:41
[B]cargo check[/C]

" Alors concrètement de quel pourcentage de vitesse les développeurs vont-ils bénéficier ? " C'est assez mal rédigé, non ?
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 18/03/2017 à 22:21
Oui, c'est un traduction assez moyenne de l'article.

Niveau vitesse ça dépend du type de code, certains type de code sont plus couteux que d'autres a compiler. Sur mes programmes, la différence par rapport entre une vérification seule et une compilation (sans optimisation) est de l'ordre de 3 à 6 fois plus rapide.

Après "make check" ne sert que a vérifier s'il y a des erreur de compilation. Si on veut tester, il faudra quand même faire une construction complète après.
Offres d'emploi IT
Ingénieur intégration, validation, qualification du système de drone H/F
Safran - Ile de France - Éragny (95610)
Responsable transverse - engagement métiers H/F
Safran - Ile de France - Corbeil-Essonnes (91100)
Architecte systèmes études & scientifiques H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil