Le processus de merge du compilateur de Rust

présenté par Guillaume Gomez

Qui suis-je ?

Reviewer et contributeur du compilateur de Rust. Membre de :
  • rustdoc team (team leader)
  • docs.rs team
  • dev-tools team


Je suis ingénieur chez Huawei.

Une pull-request est ouverte

Un reviewer est assigné par le bot rustbot...

Une pull-request est ouverte

... Et les labels sont aussi ajoutés
### Le dépôt teams [github.com/rust-lang/teams](https://github.com/rust-lang/teams)

Le site web governance

rust-lang.org/governance

Approbation

  • Si la pull request :
  • N'a pas d'impact sur les performances
  • Ne fait pas de "breaking change"
  • N'ajoute pas de nouvelle fonctionnalité
  • La CI passe

### Intégration continue Il y a 2 "niveaux" de CI : * Une partie des tests est lancée sur la pull request directement (la plupart des tests mais seulement pour linux x64) * Tous les tests sur toutes les plateformes Rien ne peut être mergé si la CI ne passe pas !
### File de build [bors.rust-lang.org/queue/rust](https://bors.rust-lang.org/queue/rust) ![bors queue](./images/queue.png)
### Qu'est-ce qui est testé ? * Compiletest * Tests unitaires * La sortie d'erreur de Rustc et Rustdoc * Les exemples de documentation * Tous les tests des outils (cargo, rustdoc, clippy, rustfmt, etc) * Les liens morts de la documentation * ... Et bien plus encore !
### Sur quel OS/architecture? * Plateforme tier 1 : Doit builder et passer les tests * Plateforme tier 2 : Doit builder * Plateforme tier 3 : Existe Politique des tiers de "target" : [doc.rust-lang.org/nightly/rustc/target-tier-policy.html](https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html) Liste des platformes pour chaque tier : [doc.rust-lang.org/rustc/platform-support.html](https://doc.rust-lang.org/rustc/platform-support.html)
### Et les releases ? En (très) bref : 1. La file de build de bors est gelée. 2. Les branches beta et stable sont mises à jour. 3. Toutes les informations (de version notamment) sont mises à jour. 4. Les binaires sont générés pour toutes les plateformes. 5. Le blog post est publié.

Performance

La pull request a été mergée, mais maintenant il est temps de vérifier si elle a eu un impact sur les performances.

perf.rust-lang.org
### Autres cas L'ajout d'une nouvelle fonctionnalité ou un changement non rétro-compatible. Trois possibilités : * RFC (Request For Comments) : Pour les gros changements * MCP (Major Compiler Changes) : Pour les changements "pas trop gros" (dans le compilateur uniquement) * FCP (Final Comment Period) : Pour les changements "pas trop gros"

Vérifier de potentielles régressions

Au cas où une pull request introduit des changements qui pourrait introduire une régression, on utilise crater.

Crater

crater.rust-lang.org

Astuces pour de potentiels nouveaux contributeurs

  • Issues avec le label E-easy ou E-mentor.
  • Le rustc dev guide : rustc-dev-guide.rust-lang.org
  • Essayez d'écrire des plugins du compilateurs ou contribuez sur clippy pour voir comment le compilateur fonctionne.


Pour vous faciliter la vie si vous souhaitez écrire des plugins du compilateur, jetez un oeil à la crate rustc-tools.

Merci pour votre attention !

More Rust things on
< blog.guillaume-gomez.fr >

< guillaume1.gomez@gmail.com >

@GuillaumeGomez
@imperio@toot.cat
@imperioworld_