Add blog post about Google Summer of Code 2024 project results

posts/2024-11-01-gsoc-2024-results.md

@@ -0,0 +1,148 @@
+---
+layout: post
+title: "Google Summer of Code 2024 results"
+author: Jakub Beránek, Jack Huey and Paul Lenz
+---
+
+As we have previously [announced][gsoc-blog-post], the Rust Project participated
+in [Google Summer of Code (GSoC)][gsoc] for the first time this year. Nine contributors have been tirelessly working on their exciting projects
+for several months. The projects had various durations; some of them have ended in August, while the last one has been
+concluded in the middle of October. Now that the final reports of all the projects have been submitted, we can happily
+announce that all nine contributors have passed the final review! That means that we have deemed all of their projects to be successful,
+even though they might not have fulfilled all of their original goals (but that was expected).
+
+We had a lot of great interactions with our GSoC contributors, and based on their feedback, it seems that they were also
+quite happy with the GSoC program and that they had learned a lot. We are of course also incredibly grateful for all their
+contributions - some of them have even continued contributing after their project has ended, which is really awesome.
+In general, we think that Google Summer of Code 2024 was a success for the Rust Project, and we are looking forward to
+participating in GSoC (or similar programs) again in the near future. If you are interested in becoming a (GSoC) contributor,
+check out our [project idea list](https://github.com/rust-lang/google-summer-of-code).
+
+Below you can find a brief summary of each of our GSoC 2024 projects, including feedback
+from the contributors and mentors themselves. You can find more information about the projects
+[here][gsoc-project-list].
+
+Max:
+"The interaction with the community and the other GSoC contributors was really great, and I think encouraging that even more would be even better for next year."
+
+### Adding lint-level configuration to cargo-semver-checks
+
+- Contributor: [Max Carr](https://github.com/suaviloquence/)
+- Mentor: [Predrag Gruevski](https://github.com/obi1kenobi)
+- [Final report](https://blog.mcarr.one/gsoc-final/)
+
+The goal of this project was to add the ability to configure lint levels to [cargo-semver-checks](https://github.com/obi1kenobi/cargo-semver-checks), a tool designed for automatically detecting semantic versioning conflicts, which might one day become a part of Cargo itself. Max has achieved this goal by implementing a [comprehensive system](https://github.com/obi1kenobi/cargo-semver-checks?tab=readme-ov-file#lint-level-configuration) for configuring `cargo-semver-checks` lints directly in the `Cargo.toml` manifest file. He has also extensively discussed the design with the Cargo team, to ensure that it is compatible with how other Cargo lints are configured.
+
+Predrag, who is the author of `cargo-semver-checks` and who mentored Max on this project, was very happy with his contributions that even went beyond his original project scope:
+
+> He designed and built one of our most-requested features, and produced design prototypes of several more features our users would love. He also observed that writing quality CLI and functional tests was hard, so he overhauled our test system to make better tests easier to make. Future work on cargo-semver-checks will be much easier thanks to the work Max put in this summer.
+
+Great work, Max!
+
+### Implementation of a Faster Register Allocator For Cranelift
+
+- Contributor: [Demilade Sonuga](https://github.com/d-sonuga)
+- Mentors: [Chris Fallin](https://github.com/cfallin) and [Amanieu d'Antras](https://github.com/Amanieu)
+- [Final report](https://d-sonuga.netlify.app/gsoc/regalloc-iii/)
+
+TODO
+
+### Improve Rust benchmark suite
+
+- Contributor: [Eitaro Kubotera](https://github.com/s7tya)
+- Mentor: [Jakub Beránek](https://github.com/kobzol)
+- [Final report](https://gist.github.com/s7tya/96dc1cae4ca9e59841a95f0f48d023d6)
+
+This project was relatively loosely defined, with the overarching goal of improving the user interface of the [Rust compiler benchmark suite](https://github.com/rust-lang/rustc-perf). Eitaro tackled this challenge from various angles at once. He improved the visualization of runtime benchmarks, which were previously a second-class citizen in the benchmark suite, by adding them to our [dashboard](https://perf.rust-lang.org/dashboard.html) and by implementing [historical charts](https://github.com/rust-lang/rustc-perf/pull/1922) of runtime benchmark results, which help us figure out how is a given benchmark behaving over a longer time span.
+
+Another improvement that he has worked on was embedding a profiler trace visualizer directly within the `rustc-perf` website. This was a challenging task, which required him to evaluate several visualizers and figure out a way how to include them within the source code of the benchmark suite in a non-disruptive way. In the end, he managed to integrate [Perfetto](https://ui.perfetto.dev/) within the suite website, and also performed various [optimizations](https://github.com/rust-lang/rustc-perf/pull/1968) to improve the performance of loading compilation profiles.
+
+Last, but not least, Eitaro also created a completely new user interface for the benchmark suite, which runs entirely in the [terminal](https://github.com/rust-lang/rustc-perf/pull/1955). Using this interface, Rust compiler contributors can examine the performance of the compiler without having to start the rustc-perf website, which can be challenging to deploy locally.
+
+Apart from the mentioned contributions, Eitaro also made a lot of other smaller improvements to various parts of the benchmark suite. Thank you for all your work!
+
+### Move cargo shell completions to Rust
+
+- Contributor: [shanmu](https://github.com/shannmu)
+- Mentor: [Ed Page](https://github.com/epage)
+- [Final report](https://hackmd.io/@PthRWaPvSmS_2Yu_GLbGpg/Hk-ficKpC)
+
+Cargo's completion scripts have been hand maintained and frequently broken when changed. The goal for this effort was to have the completions automatically generated from the definition of Cargo's command-line, with extension points for dynamically generated results.
+
+[shanmu](https://github.com/shannmu) took the prototype for dynamic completions in [clap][clap] (the command-line parser used by Cargo), got it working and tested for common shells, as well as extended the parser to cover more cases. They then added extension points for CLI's to provide custom completion results that can be generated on the fly.
+
+In the next phase, shanmu added this to nightly Cargo and added different custom completers to match what the handwritten completions do. As an example, with this feature enabled, when you type `cargo test --test=` and hit the Tab key, your shell will autocomplete all the test targets in your current Rust crate! If you are interested, see the [instructions][cargo-shell-completion] for trying this out! The link also lists where you can provide feedback.
+
+You can also check out the following issues to find out what is left before this can be stabilized:
+- [clap#3166](https://github.com/clap-rs/clap/issues/3166)
+- [cargo#14520](https://github.com/rust-lang/cargo/issues/14520)
+
+[clap]: https://github.com/clap-rs/clap
+[cargo-shell-completion]: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#native-completions
+
+### Rewriting Esoteric, Error-Prone Makefile Tests Using Robust Rust Features
+
+- Contributor: [Julien Robert](https://github.com/Oneirical)
+- Mentor: [Jieyou Xu](https://github.com/jieyouxu)
+- [Final report](https://oneirical.github.io/gsocfinal/)
+
+The Rust compiler has several test suites that make sure that it is working correctly under various conditions. One of these suites is the [`run-make` test suite][run-make], whose tests were previously written using `Makefile`s. However, this setup [posed several problems][initial-run-make-issue]. It was not possible to run the suite on the Tier 1 Windows MSVC target (`x86_64-pc-windows-msvc`) and getting it running on Windows at all was quite challenging. Furthermore, the syntax of `Makefile`s is quite esoteric, which frequently caused mistakes to go unnoticed even when reviewed by multiple people.
+
+[Julien](https://github.com/Oneirical) helped to convert the `Makefile`-based `run-make` tests into plain Rust-based tests, supported by a test support library called [`run_make_support`][run-make-support]. However, it was not a trivial "rewrite this in Rust" kind of deal. In this project, Julien:
+
+- Significantly improved the test documentation;
+- Fixed multiple bugs that were present in the `Makefile` versions that had gone unnoticed for *years* -- some tests were never testing anything or silently ignored failures, so even if the subject being tested regressed, these tests would not have caught that.
+- Added to and improved the test support library API and implementation; and
+- Improved code organization within the tests to make them easier to understand and maintain.
+
+Just to give you an idea of the scope of his work, he has ported almost [250](https://github.com/rust-lang/rust/pulls?q=is%3Apr+author%3Aoneirical+is%3Amerged) Makefile tests over the span of his GSoC project! If you like puns, check out the branch names of Julien's PRs, as they are simply *fantestic*.
+
+As a result, Julien has significantly improved the robustness of the `run-make` test suite, and improved the ergonomics of modifying existing `run-make` tests and authoring new `run-make` tests. Multiple contributors have expressed that they were more willing to work with the Rust-based `run-make` tests over the previous `Makefile` versions.
+
+The vast majority of `run-make` tests [now use the Rust-based test infrastructure][run-make-tracking-issue], with a few holdouts remaining due to various quirks. After these are resolved, we can finally rip out the legacy `Makefile` test infrastructure.
+
+[run-make]: https://github.com/rust-lang/rust/tree/master/tests/run-make
+[run-make-support]: https://github.com/rust-lang/rust/tree/master/src/tools/run-make-support
+[initial-run-make-issue]: https://github.com/rust-lang/rust/issues/40713
+[run-make-tracking-issue]: https://github.com/rust-lang/rust/issues/121876
+
+### Rewriting the Rewrite trait
+
+- Contributor: [SeoYoung Lee](https://github.com/ding-young)
+- Mentor: [Yacin Tmimi](https://github.com/ytmimi)
+- [Final report](https://ding-young.github.io/posts/gsoc-final/)
+
+TODO
+
+### Rust to .NET compiler - add support for compiling & running cargo tests
+
+- Contributor: [Fractal Fir](https://github.com/FractalFir)
+- Mentor: [Jack Huey](https://github.com/jackh726)
+- [Final report](https://fractalfir.github.io/generated_html/rustc_codegen_clr_v0_2_0.html)
+
+TODO
+
+### Sandboxed and Deterministic Proc Macro using Wasm
+
+- Contributor: [Apurva Mishra](https://github.com/mav3ri3k)
+- Mentor: [David Lattimore](https://github.com/davidlattimore)
+- [Final report](https://github.com/mav3ri3k/rust/blob/gsoc24/gsoc24.md)
+
+TODO
+
+### Tokio async support in Miri
+
+- Contributor: [Tiffany Pek Yuan](https://github.com/tiif)
+- Mentor: [Oli Scherer](https://github.com/oli-obk)
+- [Final report](https://gist.github.com/tiif/3e08ba6e8cfb1d078e6155410108ae48)
+
+TODO
+
+## Conclusion
+
+We are grateful that we could have been a part of the Google Summer of Code 2024 program, and we would also like to extend our gratitude to all our contributors! We are looking forward to joining the GSoC program again next year.
+
+[gsoc]: https://summerofcode.withgoogle.com
+[gsoc-blog-post]: https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html
+[gsoc-project-list]: https://github.com/rust-lang/google-summer-of-code/blob/main/gsoc/past/2024.md
+[gsoc-repo]: https://github.com/rust-lang/google-summer-of-code