[00:00.000 --> 00:11.000]  So we have Guillaume. He's going to talk about the merging process for the Rust compiler.
[00:11.000 --> 00:20.000]  Okay. Yeah, you can hear me. Perfect. So, hi, everyone. So, I will be talking as he mentioned
[00:20.000 --> 00:29.000]  about the merge process in the Rust compiler. So, who I am first, Rust language reviewer and contributor.
[00:29.000 --> 00:37.000]  I'm a member of a few teams. So, I'm in the Rust doc team. Not to be confused with the former documentation team.
[00:37.000 --> 00:48.000]  Also, Docs.Rust team and DevTools team. So, very documentation oriented. And I'm working at Huawei currently.
[00:48.000 --> 00:57.000]  So, we will start by taking a scenario. Hold on.
[00:57.000 --> 01:06.000]  So, when you have made a pull request, you open it. And the first thing that will happen on the pull request will be that
[01:06.000 --> 01:16.000]  the bot will assign you a reviewer. So, in this case, myself. So, very likely pull request on a Rust doc tool.
[01:16.000 --> 01:23.000]  And after that, you will have some tags. So, it's waiting on review and it's concerning the Rust doc team,
[01:23.000 --> 01:35.000]  which helps us to find the right people in case the reviewer assigned isn't available in a week, if I remember correctly.
[01:35.000 --> 01:41.000]  So, explanation a bit about how the bot is picking the people.
[01:41.000 --> 01:50.000]  So, we have a repository with the list of all teams and its members, formers and everything.
[01:50.000 --> 01:56.000]  And the bot basically pick someone from this repository.
[01:56.000 --> 02:04.000]  And this website, the governance page on the Rust long.org website is generated from it.
[02:04.000 --> 02:14.000]  So, if you need to contact someone from one of the teams, whatever reason, that's where you go.
[02:14.000 --> 02:24.000]  So, now the approval itself. So, let's say that the pull request is implemented with no request from the reviewer or anything.
[02:24.000 --> 02:40.000]  If it has no performance impact for this to have this information, if we have a depth, we have tools automated that allow us to actually check its actually the case.
[02:40.000 --> 02:48.000]  So, if needed, we just say, hey, Rust bot, can you run a perfect check on this?
[02:48.000 --> 02:55.000]  We come back to this later and we have a very nice page with some metrics and a lot of steps.
[02:55.000 --> 03:01.000]  So, another important thing is checking that there is no breaking change.
[03:01.000 --> 03:09.000]  So, of course, if you are changing something in the STD, for example, or changing how projection works on anything,
[03:09.000 --> 03:14.000]  then it becomes a lot more complex and the process becomes a lot longer.
[03:14.000 --> 03:17.000]  Same, we will come back to this later.
[03:17.000 --> 03:32.000]  So, if it adds a new feature, it's very likely that we will need to be sure at 100% that it's not something that we'll need to change or deprecate or literally just remove at some point
[03:32.000 --> 03:36.000]  because it happened a few times and it's not great.
[03:36.000 --> 03:39.000]  And obviously, the CI must pass.
[03:39.000 --> 03:45.000]  So, that's a lot of small conditions.
[03:45.000 --> 03:47.000]  So, now about the CI.
[03:47.000 --> 03:50.000]  So, there are two levels of CI.
[03:50.000 --> 03:54.000]  The one that you will see directly when you open the pull request.
[03:54.000 --> 03:58.000]  It's a lot of tests, almost all of them.
[03:58.000 --> 04:11.000]  But it's only on Linux X64 because, as you may know, we support quite a lot of targets, not as much as GCC yet, but at some point, maybe.
[04:11.000 --> 04:23.000]  And this checks, for example, if the call is wait-formatted, if you have all the tests passing, and by all the tests, I mean literally all the tests,
[04:23.000 --> 04:30.000]  so you have all the rest of the tool suite, tool test suite, the compiler error output,
[04:30.000 --> 04:38.000]  the compiler checks if the code is giving the right result, the assembly, pretty much everything,
[04:38.000 --> 04:47.000]  and it includes the tools. So, if you made a change in the compiler that breaks a tool, like REST doc, Clippy, or REST FMT,
[04:47.000 --> 04:50.000]  then we need to be aware of it right away.
[04:50.000 --> 04:54.000]  Otherwise, we are going to have quite a bite time.
[04:54.000 --> 04:58.000]  And all that is done directly on the pull request.
[04:58.000 --> 05:06.000]  So, at the current time, it takes around one hour to run this small subset.
[05:06.000 --> 05:17.000]  And when the pull request has been approved, we make the full run of all these tests and for all platforms.
[05:17.000 --> 05:29.000]  And this time, it's run, I think if I remember correctly, it's like on 40 targets or something like that, and it takes roughly around three hours.
[05:29.000 --> 05:36.000]  We have our own infra for this. We have dedicated the team for that too, the infra team.
[05:36.000 --> 05:41.000]  And I think it's currently done on AWS to be confirmed.
[05:41.000 --> 05:46.000]  But in short, nothing can be merged if the CI doesn't pass.
[05:46.000 --> 05:51.000]  We enforced this, I think it was three or four years ago.
[05:51.000 --> 06:00.000]  A few things that were merged and were expected to be fixed in very soon coming fixes were quite bad experiences,
[06:00.000 --> 06:04.000]  and we decided to have a zero-tolerance policy.
[06:04.000 --> 06:09.000]  It's working quite nice, so currently we keep it.
[06:09.000 --> 06:11.000]  So now it's a build queue.
[06:11.000 --> 06:21.000]  When we approve the command with the pull request with the command AddBulls R+, you might have seen it or not.
[06:21.000 --> 06:28.000]  We have a build queue, and that's where you can see pretty much everything that is happening.
[06:28.000 --> 06:33.000]  So in the current case, you see the pull request, the first one which is pending.
[06:33.000 --> 06:40.000]  So it allows you to see what is being tested and eventually how long it remains.
[06:40.000 --> 06:44.000]  And you can see also everything that is approved and everything.
[06:44.000 --> 06:51.000]  And it's sorted by priority first, which you can see because I had to make a small screenshot.
[06:51.000 --> 06:57.000]  And the second thing is how old the pull request is.
[06:57.000 --> 07:05.000]  We generally have around 20 pull requests at the same time in this build queue.
[07:05.000 --> 07:10.000]  So to make things faster, we have what we call a roll-up process.
[07:10.000 --> 07:16.000]  We group a full pull request that we are sure have no performance impact or anything.
[07:16.000 --> 07:20.000]  And we say, okay, make a roll-up of five pull requests.
[07:20.000 --> 07:23.000]  You can see the button, create a roll-up.
[07:23.000 --> 07:27.000]  So we pick a few pull requests and we click on the button,
[07:27.000 --> 07:31.000]  and it generates a pull request for us with our account.
[07:31.000 --> 07:35.000]  And after that, we give it quite a high priority and like that,
[07:35.000 --> 07:39.000]  we can have a big bunch of pull requests to merge at once.
[07:39.000 --> 07:41.000]  Very useful.
[07:41.000 --> 07:44.000]  And that is for the build queue.
[07:44.000 --> 07:48.000]  So what I explained a bit before, what is tested.
[07:48.000 --> 07:50.000]  So we have the compile test.
[07:50.000 --> 07:54.000]  So if your code is supposed to compile or not,
[07:54.000 --> 08:01.000]  because, for example, we want to ensure certain cases in very weird cases that don't compile
[08:01.000 --> 08:04.000]  or in other cases compile.
[08:04.000 --> 08:09.000]  And that's how you can discover things like you can't implement directly on projections.
[08:09.000 --> 08:13.000]  And if that doesn't speak much to you, it's a good sign.
[08:13.000 --> 08:16.000]  We have all the unit tests.
[08:16.000 --> 08:19.000]  Unit tests are mostly for the tools.
[08:19.000 --> 08:28.000]  But we have a few tests with, like I mentioned, just below the error output.
[08:28.000 --> 08:30.000]  It's quite important.
[08:30.000 --> 08:37.000]  So we ensure that the Rust doc and the Rusty errors are looking exactly as you might expect.
[08:37.000 --> 08:42.000]  If you ever used, and I think a lot of you used already Rust,
[08:42.000 --> 08:48.000]  you might have appreciated the errors and the output.
[08:48.000 --> 08:51.000]  Yes, because they are very, very strongly tested.
[08:51.000 --> 08:56.000]  Currently, just for the UI test, we have around 20,000 tests.
[08:56.000 --> 08:58.000]  So it's quite monstrous.
[08:58.000 --> 09:01.000]  And running it takes quite some time.
[09:01.000 --> 09:04.000]  I think it's, well, at least 10 minutes, something like that.
[09:04.000 --> 09:06.000]  It's quite heavy.
[09:06.000 --> 09:12.000]  Maybe you don't know it, but the documentation example are tested, all of them.
[09:12.000 --> 09:17.000]  You can just test them manually in your code by running cargo test.
[09:17.000 --> 09:21.000]  The cargo tool will take all the unit tests in your code.
[09:21.000 --> 09:24.000]  The test folder will run on everything.
[09:24.000 --> 09:28.000]  And it includes, of course, everything that is in the documentation.
[09:28.000 --> 09:39.000]  So that allows us to reduce the maintenance burden by being sure that we don't give examples that are not compiling anymore
[09:39.000 --> 09:42.000]  or completely broken, quite useful.
[09:42.000 --> 09:44.000]  Once again, it reduces the burden.
[09:44.000 --> 09:47.000]  And, of course, we have all the tools.
[09:47.000 --> 09:50.000]  So cargo, RustDoc, Clippy, RustFMT.
[09:50.000 --> 09:54.000]  So as I mentioned, when you change something on the compiler, sorry,
[09:54.000 --> 09:57.000]  when you change something in the compiler,
[09:57.000 --> 10:01.000]  since these tools are using directly the compiler,
[10:01.000 --> 10:04.000]  they are actually compiler extensions except cargo.
[10:04.000 --> 10:09.000]  Cargo is just tested to ensure that not a new option is breaking something.
[10:09.000 --> 10:16.000]  So for the others, they are extensions of the compiler and we need to ensure that no changes is breaking anything
[10:16.000 --> 10:19.000]  because that would be problematic.
[10:19.000 --> 10:26.000]  We generate a lot of documentation and we have to ensure that we have no deadlinks.
[10:26.000 --> 10:31.000]  And, in fact, we do have some of them and we ignore them on purpose.
[10:31.000 --> 10:32.000]  So sorry for that.
[10:32.000 --> 10:38.000]  We can't fix them because, funnily enough, in the STD, we re-export stuff that is in the core
[10:38.000 --> 10:40.000]  and they share the same documentation.
[10:40.000 --> 10:45.000]  So if you are looking at the documentation in the STD pages,
[10:45.000 --> 10:49.000]  all the links are working in the core create.
[10:49.000 --> 10:50.000]  They're not.
[10:50.000 --> 10:53.000]  So try to use STD as much as possible.
[10:53.000 --> 10:57.000]  And it's just very basic, but we have quite a lot more.
[10:57.000 --> 11:02.000]  We mentioned in the previous talk, the inline assembly, it's part of the things.
[11:02.000 --> 11:11.000]  Something we realized when working on the GCC backend this time is that GCC doesn't allow to specify a syntax
[11:11.000 --> 11:14.000]  that's thanks to this test suite.
[11:14.000 --> 11:19.000]  So currently, we can't implement all features and it's going to take quite a long time,
[11:19.000 --> 11:23.000]  but hopefully at some point, someone motivated will do it.
[11:23.000 --> 11:25.000]  Don't know.
[11:25.000 --> 11:30.000]  So on which OS and architectures are tested, everything.
[11:30.000 --> 11:34.000]  We have target tier policy.
[11:34.000 --> 11:38.000]  You can go check it on the page just linked below.
[11:38.000 --> 11:43.000]  But basically tier one, the platforms are the platforms that are fully tested,
[11:43.000 --> 11:45.000]  implemented, and everything.
[11:45.000 --> 11:48.000]  So macOS, Linux, and Windows.
[11:48.000 --> 11:55.000]  And they must pass all the tests and we build them and we ensure that what we have built
[11:55.000 --> 12:01.000]  and has to be able to be uncomplaced and working on the target and everything.
[12:01.000 --> 12:04.000]  So strict, very strict restriction.
[12:04.000 --> 12:08.000]  On the tier two platforms, it's a lot more relaxed.
[12:08.000 --> 12:10.000]  We just need it to build.
[12:10.000 --> 12:12.000]  If it works, well, it's good.
[12:12.000 --> 12:15.000]  If it doesn't, well, too bad.
[12:15.000 --> 12:19.000]  And for the tier three platforms, it exists.
[12:19.000 --> 12:21.000]  Yeah, that's good.
[12:21.000 --> 12:27.000]  So for example, if you want to build on the Nintendo 3DS, you can.
[12:27.000 --> 12:30.000]  We don't know if it would work, but you can.
[12:30.000 --> 12:36.000]  And you can see the list of the platforms each tier on the page just below.
[12:36.000 --> 12:42.000]  Like I mentioned, we have quite a lot and we hope to be able to expand it a bit more
[12:42.000 --> 12:47.000]  by adding at least the GCC backend at some point.
[12:47.000 --> 12:50.000]  A lot of work remaining.
[12:50.000 --> 12:52.000]  So what about releases now?
[12:52.000 --> 12:56.000]  Because as you might know, we make a release every six weeks.
[12:56.000 --> 13:00.000]  So it's very fast release cycle.
[13:00.000 --> 13:04.000]  So when this happens, the build queue is frozen.
[13:04.000 --> 13:09.000]  We don't allow anything below like a priority of 10,000 to be merged.
[13:09.000 --> 13:15.000]  It's a completely random number, but generally if you go higher than 10, it's quite important.
[13:15.000 --> 13:18.000]  So in this case, we freeze everything.
[13:18.000 --> 13:27.000]  And the only things allowed to be merged are the patches to make actually the stable and beta branches update.
[13:27.000 --> 13:35.000]  An important thing that isn't noted here is that we don't have the need to freeze for the nightly.
[13:35.000 --> 13:41.000]  We just say at a given time of every day, okay, this will be the nightly version for today.
[13:41.000 --> 13:44.000]  Yay, and that's it.
[13:44.000 --> 13:48.000]  So back to this, the third point.
[13:48.000 --> 13:52.000]  All relevant information is updated and reared.
[13:52.000 --> 13:59.000]  And by that, I mean the websites, the documentation, the book, I think, too.
[13:59.000 --> 14:00.000]  Pretty much everything.
[14:00.000 --> 14:02.000]  We generate the binaries.
[14:02.000 --> 14:04.000]  So that's what I mentioned.
[14:04.000 --> 14:11.000]  That's the things that need to be working for at least tier one polyform.
[14:11.000 --> 14:14.000]  And of course, we make a blog post.
[14:14.000 --> 14:21.000]  Generally, the blog post is written not for the current stable release, but we write it at the beta version.
[14:21.000 --> 14:29.000]  And then depending if we need the backports, for example, we realize that in the current beta version,
[14:29.000 --> 14:32.000]  something is completely broken and we don't want that.
[14:32.000 --> 14:34.000]  And it's an easy enough fix.
[14:34.000 --> 14:41.000]  Either we backport a patch that was merged on the nightly directly onto the beta branch.
[14:41.000 --> 14:43.000]  Or we say, okay, too bad.
[14:43.000 --> 14:47.000]  We revert that and we'll do it the next time.
[14:47.000 --> 14:49.000]  It happened quite a lot.
[14:49.000 --> 14:52.000]  And it's not uncommon.
[14:52.000 --> 14:54.000]  Let's just say it's better if it doesn't happen.
[14:54.000 --> 15:02.000]  It allows us to not have the dot one version coming up like a three days later because we realize that we broke something.
[15:02.000 --> 15:06.000]  And the blog post is released.
[15:06.000 --> 15:08.000]  So now a performance.
[15:08.000 --> 15:13.000]  What I mentioned is that we need to check sometimes the performance.
[15:13.000 --> 15:15.000]  So we have to speed it now.
[15:15.000 --> 15:21.000]  So for the performance, we have a lot of benchmarks you can see on the left.
[15:21.000 --> 15:25.000]  It's generally for the number of instructions that have been written.
[15:25.000 --> 15:33.000]  It's what we consider the most important metric and most, let's say, stable.
[15:33.000 --> 15:41.000]  So when you have all green numbers and quite high, oh, yeah, 8%, yeah, that's quite right.
[15:41.000 --> 15:45.000]  So when you have all green numbers, it's green and everyone is parting.
[15:45.000 --> 15:54.000]  And if you have all red numbers, either you have a very good reason or it's not going to be merged until you can make them at least black.
[15:54.000 --> 16:05.000]  And we have, like I said, a lot of metrics like cycles, memory usage, disk usage, because we started to worry about the binary size.
[16:05.000 --> 16:12.000]  We realized that all the doc attributes were generated in the binaries, which is not great.
[16:12.000 --> 16:14.000]  So we are going to fix that at some point.
[16:14.000 --> 16:18.000]  And you can see on the right that, yeah, maybe you can see.
[16:18.000 --> 16:26.000]  Anyway, just to believe what I say, the results are showed in the nice comment directly on the pull request.
[16:26.000 --> 16:34.000]  So other cases, when you add a new feature or introduce a breaking change, there are three possibilities.
[16:34.000 --> 16:38.000]  The mostly non-one is the RFC, request for comments.
[16:38.000 --> 16:40.000]  It has its own repository.
[16:40.000 --> 16:43.000]  It takes a lot of time and effort and comments.
[16:43.000 --> 16:50.000]  It can go really fast, like two days, or it can take indefinite amount of time.
[16:50.000 --> 17:00.000]  Some examples, some RFCs have been open and still are commented on before the 1.0, so that gives you an idea.
[17:00.000 --> 17:03.000]  We have the MCP, major compiler changes.
[17:03.000 --> 17:05.000]  So not too big changes in the compiler.
[17:05.000 --> 17:08.000]  We find it not to greet how the query system is working.
[17:08.000 --> 17:14.000]  So let's try this solution, and they discuss mostly design and very technical points.
[17:14.000 --> 17:19.000]  Interesting, but if you don't know this area, well, it's not very understandable.
[17:19.000 --> 17:22.000]  And the last one is common to all teams.
[17:22.000 --> 17:26.000]  So the FCP, the final comment period, it's something that we want.
[17:26.000 --> 17:29.000]  And we just want to be sure that everyone is on board.
[17:29.000 --> 17:40.000]  So we ask for an FCP, and once more than half of the members of the team are okay with it, then we approve it, and here we go.
[17:40.000 --> 17:48.000]  So we, of course, for every poll request that is merged, we check for potential examples.
[17:48.000 --> 17:50.000]  No, that's before, sorry.
[17:50.000 --> 17:57.000]  When we make a new feature that potentially changes current behavior,
[17:57.000 --> 18:02.000]  we look for potential regressions in all the crates ecosystem.
[18:02.000 --> 18:05.000]  So we make what we call a crater run.
[18:05.000 --> 18:13.000]  And with this version of your code, we run on all crates, and we generate a nice report.
[18:13.000 --> 18:15.000]  You can see on the left.
[18:15.000 --> 18:19.000]  And if you only have flaky stuff, we say, okay, no impact.
[18:19.000 --> 18:20.000]  So it's good.
[18:20.000 --> 18:23.000]  We don't care, and that's pretty much it.
[18:23.000 --> 18:31.000]  And same as for the performance, we have a nice comment explaining everything in short,
[18:31.000 --> 18:36.000]  which is much more easy to read that the thing on the left, which is actually not good.
[18:36.000 --> 18:44.000]  And now a little part I like to do every time, tips for potential new contributors.
[18:44.000 --> 18:54.000]  We have a lot of classified tagged issues with ELZ or E-Monitor or both issues.
[18:54.000 --> 18:57.000]  Take a look at them.
[18:57.000 --> 19:01.000]  We try to be as helpful as possible to newcomers.
[19:01.000 --> 19:04.000]  It's important for us to have new blood.
[19:04.000 --> 19:08.000]  We have always good surprises with newcomers.
[19:08.000 --> 19:14.000]  We wrote a receipt of guide, which is not up-to-date at all.
[19:14.000 --> 19:21.000]  So at least you have a vague idea of what's going on, because I think not many people have an idea.
[19:21.000 --> 19:28.000]  And you can try also to write compiler plugins or eventually contribute to ClipIt
[19:28.000 --> 19:32.000]  to see how the compiler higher internal levels work.
[19:32.000 --> 19:38.000]  About ClipIt, it's really simple to contribute to it, like they have a full guide or anything.
[19:38.000 --> 19:43.000]  So if you want a big, nice first step, take a look at ClipIt and how it works,
[19:43.000 --> 19:47.000]  and it gives a very, very nice introduction.
[19:47.000 --> 19:52.000]  And I am making publicity for myself.
[19:52.000 --> 20:00.000]  I wrote a small receipt towards Crate, which makes a few things simpler to write plugins and extensions to the compiler.
[20:00.000 --> 20:03.000]  If you want to write, go ahead.
[20:03.000 --> 20:06.000]  It's made to be usable as much as possible.
[20:06.000 --> 20:08.000]  And thank you for listening.
[20:08.000 --> 20:31.000]  Thank you so much for watching.