Google Summer of Code 2026 results

The Rust Project participated in Google Summer of Code (GSoC) for the third time this year.

This time we had 13 projects, and our dear contributors have been working very hard on them for several months.

As usual, the projects had various durations, so while some of them have ended in August, the last one has only finished in November, so we have been waiting until we have all the results before publishing this blog post. We are very happy to announce that all 13 projects were successful and passed their final evaluation!

We consider it to be a testament to the diligence of our contributors, and the helpfulness of our mentors, that we are able to keep a very high rate[1] of successful GSoC projects several years in a row. At the start of summer, we had a video call with our contributors, so that we could all get to know each other a bit, and learn about their projects.

Over the following few months, we continuously communicated with the contributors, provided guidance and answered their questions and reviewed their pull requests. And most importantly, we learned many new things together!

It was an overall great experience. We are grateful for all Rust contributions done by our GSoC participants and for the time we spent working together, and we hope that we will continue seeing at least some of them around in the future. We would like to thank all our Rust GSoC 2026 contributors.

You did a great job! Even though this year we had fewer projects than in 2025, mostly due to limited mentoring capacity, Google Summer of Code 2026 was again a success for the Rust Project. We think that GSoC is a great way of introducing new contributors to our community, and we are looking forward to participating in GSoC (and other mentorship programs, such as Outreachy) again in the near future.

If you are interested in becoming a (GSoC) contributor, check out our GSoC project idea list and our guide for new contributors. Below you can find a brief summary of our GSoC 2026 projects. You can find more information about the original goals of the projects here.

For easier navigation, here is an index of the project descriptions in alphabetical order: A Frontend for Safe GPU Offloading in Rust by Marcelo Domínguez Adding WebAssembly Linking Support to Wild by Kei Akiyama Bringing autodiff and offload into Rust CI by Shota Sugano Debugger for Miri by Mohamed Ali Implementing impl and mut restrictions by Ryosuke Yamano Improving Ergonomics and Safety of serialport-rs by Tanmay libc: transition differing bit-width time and offset variants and deprecate bug-prone constants by Adam Martinez Link Linux kernel and its Modules with Wild by Vishruth Thimmaiah Migrating rust-analyzer assists to SyntaxEditor by bit-aloo Port std::arch test suite to rust-lang/rust by Sumit Kumar Reorganizing tests/ui/issues by zedddie Utilize debugger APIs to improve debug info test accuracy and error reporting by Anthony Bolden XDG path support for rustup by Guicheng Liu And now strap in, as there is a ton of great content to read about here!

A Frontend for Safe GPU Offloading in Rust Contributor: Marcelo Domínguez Mentor: Manuel Drehwald Final report Marcelo worked on improving the usability of cross-vendor GPU programs in Rust using the std::offload module. At the start of the project, the offload prototype was only a proof of concept. It assumed that the offloaded code was bug-free, and it required users to write a lot of boilerplate code.

Marcelo resolved both issues over the summer. First, he implemented proper type checking. Marcelo extended the compiler to verify that the arguments passed to any offload call are of the correct type, as expected by the GPU kernel.

Kernel launches are thus now safe. After that, he added support for generic kernels. The compiler now collects all generic instantiations launched from the CPU side, and loads that info later when compiling GPU kernels to make sure we instantiate them as needed.

Marcelo also added support to select which GPU to use, which is helpful for laptops with both an integrated and a dedicated GPU, as well as for servers with multiple GPUs. He also added two macros that removed the need for any boilerplate when writing and launching GPU kernels. The hardest part of this project by far was dealing with references.

Due to Rust semantics, we cannot just map types containing mutable references to GPUs and then process them using multiple threads. Previous Rust GPU projects used raw pointers as a workaround, but we obviously wanted to avoid those. Marcelo managed to implement a sound abstraction so that users can now safely declare how their kernels will access mutable arguments.

As a cherry on top, Marcelo also ported the RajaPerf performance suite from C++ to Rust and used it to benchmark his pull requests. His safe Rust version matches the performance of the original C++ code, and is now described in a GPU offload paper that he is working on together with his mentor, Manuel. This was Marcelo's second Rust GSoC project, and same as last year, we are very happy with the results.

Great job! Adding WebAssembly Linking Support to Wild Contributor: Kei Akiyama Mentor: David Lattimore Final report The goal of this project was simple on paper: teach the Wild linker to link WebAssembly (Wasm) programs. However, adding support for a new linker target is of course far from simple. Luckily, Kei already had a lot of experience with Wild, as this was his second GSoC project working on the Wild linker.

And as expected, Kei did a great job! Prior to GSoC 2026, Wild had no Wasm output support. Now, the Wasm support is sufficiently good that Wild can link a range of complex programs to Wasm.

For example, it is able to link itself, SQLite, ripgrep, CPython and even the SpiderMonkey JavaScript engine. And the linking performance is excellent! When compared to wasm-ld, the de-facto standard Wasm linker, which is based on the LLD linker, Wild is 2-15x faster, and uses 2-5x less memory.

You can find more benchmarks in his final report, where he also explains that achieving this performance took quite some work, because Wild's ELF linking performance did not immediately translate to being fast when linking Wasm. Even after this GSoC project ended, Kei has continued improving Wild's Wasm support, as well as contributing to other parts of Wild.

Thank you for bringing fast linking to a new set of use-cases, Kei! You are a valued member of the Wild team.

Bringing autodiff and offload into Rust CI Contributor: Shota Sugano Mentor: Manuel Drehwald Final report The goal of this project was to build the experimental std::autodiff module, which implements automatic differentiation of Rust code, and the std::offload module, which allows offloading Rust code to GPUs, in the CI of the Rust compiler.

Shota has already been contributing to this area in the months leading up to this year's GSoC, so he had no issues getting started. After valiantly fighting with our CI, he made both modules available in the official nightly compiler channel. Rust users can thus now simply install them with a single rustup command, rather than having to compile rustc from source!

This is a huge benefit for gathering feedback on these features in the wild, as it makes it much easier to experiment with them. Beyond making these projects available via rustup, he also worked on making it simpler to build projects that use std::offload. The original compilation pipeline was derived from Clang's support for GPU offload, so it involved calling clang helper binaries.

That is clearly not optimal, so Shota worked on replacing it by directly calling the underlying LLVM APIs from rustc. The last piece of his project was enabling testing in CI for both offload and autodiff, which already helped prevent multiple regressions.

Right now, the GPU offload pipeline only tests the CPU setup side, but his work allowed us to talk to GPU hardware vendors, two of which already agreed to provide the Rust Project with GPU hardware so that in the future we can also run those tests on dedicated GPUs. Overall, the project was a success. Shota had to show a lot of patience and endurance when working with various CMake quirks and CI challenges.

We would like to extend a special thank you for that! Debugger for Miri Contributor: Mohamed Ali Mentor: Oli Scherer Final report miri is a tool that can detect undefined behavior (UB) in unsafe Rust code. It used to have a prototype of an interactive debugger called priroda, but it became unmaintained some time ago.

The goal of this project was to re-establish priroda, to make it easier to use miri interactively, debug how and why is UB introduced in Rust programs, and also help rustc developers analyse MIR, one of the intermediate representations of Rust programs. Mohamed successfully reached both main goals of this project. He created a miri interface for the gdb debugger, which allows debugging programs executed by miri.

You can set breakpoints, step through individual instructions, analyse MIR local variables and inspect the debugged program's state, with miri acting as a "virtual CPU". So when you encounter your next miri UB report, you can actually debug the program state that caused UB by running priroda! Mohamed also created a command-line interface for priroda, which is used to test it in miri's CI.

This will ensure that it keeps working properly and will not bitrot again. Mohamed also added basic support for the Debugger Adapter Protocol, which allows using priroda together with IDEs such as Visual Studio Code.

Currently, connecting priroda to an IDE is a bit involved, so the next step would be to build a plugin for an IDE that would allow showing all the extra state that miri has, which gdb doesn't know how to interpret. Debugging programs executed by miri is very exciting.

Thank you for all your work! Implementing impl and mut restrictions Contributor: Ryosuke Yamano Mentors: Jacob Pratt, Urgau Final report The goal of this project was to implement two new language features that were accepted in RFC 3323: Impl restrictions (impl(crate) trait Foo {}), which allow restricting in which modules you are able to implement a given trait.

Mut restrictions (struct Foo { pub mut(crate) bar: u8 }), which allow restricting in which modules you are able to mutate a given field. Ryosuke had to familiarize himself with the compiler's codebase and do a lot of implementation work to get both features working.

This included implementing parsing of the new syntax, recording its metadata in the compiler's Abstract Syntax Tree, implementing resolution of the restricted crate paths, and finally adding checks to enforce both restriction rules. This all amounted to around five thousand lines of Rust code! Once the new features were implemented and available on nightly, Ryosuke wrote a Call for Testing blog post.

It had to be very exciting to announce to the world that he implemented two new features from scratch, and people can now play with them on the nightly channel! After the blog post was published, users reported a few issues, which Ryosuke promptly fixed. He also contributed to rustdoc to improve how the impl and mut restrictions are rendered in the generated documentation pages.

Now that the features are available on nightly, feedback is being gathered on them, with the plan being to stabilize them in 2027. If you would like to provide feedback on the impl and mut restrictions, you can do so in this issue. The goal of this project was clear, and Ryosuke achieved it completely.

Awesome work! Improving Ergonomics and Safety of serialport-rs Contributor: Tanmay Mentor: Christian Meusel Final report The goal of this project, which was done in collaboration with the Rust Embedded Working Group, was to improve the API ergonomics and type safety of the serialport-rs crate. The serialport project is a bit different from some other projects which participated in this year's Google Summer of Code.

It is more on the side of "facility management" than rocket science. Its challenges are taming finicky operating system APIs and making good abstractions, rather than full-blown software engineering.

Tanmay led many fruitful discussions about potential design decisions, and did a lot of field research on how other crates that depend on serialport actually use its API, to figure out how to make the upcoming breaking API changes less disruptive and painful for them.

Tanmay also worked on sanding off some rough edges of the serialport API, such as replacing Boxed trait objects with enums, and making errors explicit in places where the legacy API used to panic. Some of the work still waits for integration. It is targeting the upcoming serialport 5.0 release.

Christian (Tanmay's mentor) found working alongside Tanmay very motivational, and he was able to catch up with a lot of other unrelated work in order to integrate Tanmay's changes. He noted that working with Tanmay was fun and productive, and that it was pure joy to see him grow from his first contribution in the bonding phase to seasoned contributions.

Thank you, Tanmay! This was my first Google Summer of Code as well. It was challenging, motivating, fun and definitely worth it. I would show up again. Christian Meusel This was my first Google Summer of Code as well.

It was challenging, motivating, fun and definitely worth it. I would show up again. Christian Meusel libc: transition differing bit-width time and offset variants and deprecate bug-prone constants Contributor: Adam Martinez Mentor: Trevor Gross Final report libc is a foundational crate that is used by thousands of other crates across the Rust ecosystem.

For the past several years, its maintainers have been attempting to publish a stable 1.0 release of the crate. Because this crate has to support interoperating with C on many compilation targets with weird quirks, this requires an enormous amount of work. We already had a GSoC project for moving libc towards 1.0 last year, and the goal of Adam's project was to make more progress in that direction.

And we can happily say that progress was indeed made! The original goal of Adam's project was to deprecate a number of constants that were difficult to maintain and cleanup inconsistencies in handling 32-bit/64-bit variants of file and time handling functions[2]. Adam was able to resolve that in a few weeks, and then he moved on to resolve a number of various issues blocking the 1.0 milestone.

Saying that Adam was productive would be… an understatement. We could follow his work in real-time, because he was posting daily GSoC reports for 116 days (!) in a row. The diligence and consistency with which he tackled so many complicated issues was an inspiration to us.

In fact, sometimes the libc reviewers were not able to keep up! You can find all Adam's libc pull requests here. You might notice that many of them have lots of comments, and even more discussions happened in GitHub issues and on Zulip.

In addition to implementing the necessary code, making changes that affect interesting C platforms and architectures also required him to do a ton of research, and a lot of considerations of edge cases and possible backwards compatibility breakages. His work also took him on a whirlwind tour of diverse platforms; Adam's contributions spanned FreeBSD, NetBSD, Android, Hurd, NuttX, AIX, VxWorks, Fuchsia, L4Re and more.

Even though more work will still be required to get libc to 1.0, Adam's contributions made a significant dent in this effort. Thank you very much for all your work! Link Linux kernel and its Modules with Wild Contributor: Vishruth Thimmaiah Mentor: David Lattimore Final report Linker scripts are arcane commands that can be used to instruct a linker to construct the final binary in a custom way.

The Wild linker used to implement only basic linker script functionality, which Vishruth greatly expanded during his GSoC project. Thanks to that, Wild can now successfully link Linux kernel modules, and it's even close to being able to link the Linux kernel itself! Vishruth's work involved greatly expanding expression evaluation support, location counters, program headers, etc.

In addition to adding support for many missing bits of linker script support, Vishruth implemented support for partial linking (-r) as this is needed in order to link Linux kernel modules. You can find all the linker script features that he implemented here. Adding all those peculiar features to Wild required performing many cross-cutting changes to its codebase, which Vishruth managed to do really well.

And it was not at the cost of performance! Wild now manages to link Linux kernel modules such as btrfs or amdgpu 2-4x faster than the BFD (GNU ld) or LLD linkers[3]. You can find more benchmarks in his final report.

Vishruth has continued to contribute to Wild even after his GSoC project ended and has become a valued contributor to the project. Thank you very much for making Wild better, Vishruth!

Migrating rust-analyzer assists to SyntaxEditor Contributor: bit-aloo Mentors: Chayim Refael Friedman, Lukas Wirth Final report rust-analyzer uses rowan for its syntax trees, a library for Concrete Syntax Trees. rowan has served us well over the years, but it has some downsides that cause major performance problems and also smaller convenience issues.

In particular, memory fragmentation causes rust-analyzer to consume much more memory than it actually needs (in the order of redundant gigabytes). We wanted to rewrite rowan to change that. The problem was that many parts in rust-analyzer touch syntax trees, and in particular assists (code actions) of which we have a lot.

They also use mutable tree editing, a feature of rowan that can be convenient but was a major obstacle in rewriting it to be more efficient. During his project, bit-aloo first migrated all rust-analyzer code from mutable tree editing to SyntaxEditor, a new abstraction that was created specifically to avoid mutation. After that, he removed mutable editing from rowan altogether.

The migration process is incremental and rowan is still inefficient in various aspects. However, we believe that the parts which required changes to large amounts of code are behind us, and we can complete the migration with more focused changes. bit-aloo is continuing to work on that even after his GSoC project ended. And he was also accepted as a member of the rust-analyzer team, so congratulations!

We would like to thank him for his work, and hope to continue working with him to improve rust-analyzer for everyone. Port std::arch test suite to rust-lang/rust Contributor: Sumit Kumar Mentors: Jakub Beránek, Folkert de Vries Final report The std::arch module of the Rust standard library contains various intrinsic functions that provide architecture and vendor-specific functionality.

Their implementation lives in the stdarch repository, which is included as a Josh subtree in the main compiler repo (rust-lang/rust). When someone changes the intrinsics in the main repo, breakages can silently creep in, because the main repo does not execute all the stdarch tests in its CI. That can cause friction when we synchronize the changes between the two repositories.

Ideally, we would run all of stdarch's tests in the main repo to detect any issues as soon as possible. And that is where Sumit came in! Over the course of his GSoC project, he examined the (very!) complex ways the intrinsics are tested in stdarch, and started porting them over to the main repo.

But this was not a matter of copying over a few lines of YAML. The compiler repo uses its own build system (called bootstrap) and a CI workflow structure that is quite different from the stdarch repository. Sumit thus had to first understand what is each test suite doing, reimplement it as a part of bootstrap and finally integrate it into the compiler's CI workflows.

We run ~90 CI jobs across several hardware architectures, operating systems and OS versions. Getting all that to work while testing vendor-specific intrinsics required a lot of diligent work… and a lot of patience. It took five months for one of the test suites to finally succeed on the main repo's CI, and it required Sumit to completely refactor how the suite worked, for it to be more compatible with bootstrap.

As another example, a different test suite that Sumit also got to work required running the tests in an Intel CPU emulator on CI. Sumit ported most of the stdarch test suites to bootstrap, including intrinsics verification against reference C implementations, checks for automatically generated source code being up-to-date, and various unit tests for individual intrinsics and CPU feature detection logic.

There is one remaining test suite to port, but the ported tests are already helping us find issues, which is great. You can check Sumit's rust-lang PRs here; notice that he was also contributing to other parts of Rust in the meantime! Sumit's work will help us make LLVM upgrades and land intrinsics changes more easily.

Thank you, Sumit! Reorganizing tests/ui/issues Contributor: zedddie Mentors: Teapot, Kivooeo Final report The goal of this project was to get rid of a very scary place in the Rust compiler's test suite: a directory called tests/ui/issues. It contained thousands of test files based on historical Rust issues, dating back all the way to 2012.

The problem with those tests was that they were named only with an issue number (e.g. issue-37291). When such a test would break, it was quite difficult to figure out what was it even supposed to test, because there was little context attached to it.

Even though we already had a GSoC project to tackle this problem last year, due to the sheer amount of uncategorized tests, there were still over four hundred tests left in this directory by the time zedddie started working on this project. For each test in this directory, zedddie had to first understand what was the test doing and dig through its original GitHub issue and any other related issues and pull requests.

Then they had to figure out what would be the best location to move the test under, search for any possible duplicates, come up with a descriptive name for the test (that tends to be very difficult!), and finally add a short description to the test that explains the context of why the test was added in the first place.

Rinse and repeat, for hundreds of tests. zedddie rolled up their sleeves, and categorized over 300 tests in 30 pull requests. Together with other contributors helping out over this summer, zedddie was finally able to remove the last batch of uncategorized tests at the start of August. As zedddie said in their final report: "What is left to do: nothing, tests/ui/issues is gone".

While this work might sound a bit bland, its positive effect on the maintainability of our test suite, and improving the lives of Rust compiler contributors, is considerable. It is also apparently a great way to learn about cool niche edge cases of Rust that most Rust developers might not know about!

After migrating the remaining uncategorized UI tests, zedddie continued contributing to the next trait solver and const generics. Thank you very much for helping us finally get rid of tests/ui/issues, zedddie! Utilize debugger APIs to improve debug info test accuracy and error reporting Contributor: Anthony Bolden Mentors: Jakub Beránek, Jieyou Xu Final report The Rust debugging experience leaves a lot to be desired.

One reason why we struggled to improve it is that many of our debuginfo test suites did not even run in CI for the past few years, as they were difficult to maintain. When something changed in the type visualizers, the implementation details of a standard library type or in debugger internals, someone had to go through tens of tests and manually update them. This was not sustainable, so the test suite rotted.

Luckily for us, Anthony took that affront personally. Even before his GSoC project, he spent considerable effort on improving the quality of debug visualizers of various Rust standard library types, and gained an impressive amount of knowledge about debuggers. During his GSoC project, he completely overhauled how our debuginfo test infrastructure works, both for LLDB and GDB.

Thanks to his improvements, we can now easily "rebless" the reference output when something changes, which makes it much easier to keep our test suite up-to-date. The new tests also record much more information about the internal state of the debugger recorded during the test, which helps with diagnosing issues that cause type visualizers to stop working.

In addition to redesigning the test suite, Anthony also actually managed to re-enable the LLDB tests on both Windows and Linux in our CI again (after several years of being skipped there!). This will allow us to avoid debuginfo regressions and make it easier to improve the Rust debugging experience. Oh, and it goes without saying that while doing all that, he also made numerous improvements to Rust type visualizers.

You can find his PRs here. Anthony's amazing contributions and his deep expertise in debuggers led to him being invited to the Rust Compiler team, which was much deserved. What else can we add, other than: thank you for your awesome work!

XDG path support for rustup Contributor: Guicheng Liu Mentor: rami3l Final report The support for platform-specific directories (platformdirs) has been a long-standing feature request for rustup, to have more fine-grained filesystem directory choices. This project investigated how that issue could be resolved.

The real complexity of this feature request lies within a decade worth of different assumptions that previous iterations of rustup and cargo have made: it turns out that quite a lot of them are no longer true if we were to implement platformdirs support truly faithfully. Guicheng first worked on cleaning up the interactions between rustup self uninstall and $CARGO_HOME/bin as a warmup.

This issue itself is a very good demonstration of all that compatibility baggage: somehow $CARGO_HOME/bin has become the default binary directory for all things Rust, so rustup ended up installing itself and all its proxies into it. As a result, it has been super annoying to many that everything in $CARGO_HOME is gone with rustup self uninstall.

After that, he started the actual implementation of platformdirs support in rustup. This was no easy task! Not because the code itself was hard to write, but because it takes a lot of effort to figure out what should be the desired behavior in the first place.

Also, in order to determine the appropriate platformdirs semantics, some prior research is often required to see how things became what they are today, so the decoupling of different concerns could proceed, and migration paths could be designed accordingly.

It was in this sense that this is different from a typical GSoC project, and luckily thanks to the effort he has put into this project, we have not only come up with the final patch, but also discovered and fixed some tiny preexisting issues with this long-untouched aspect of the rustup codebase along the way. Thank you for digging into this complex topic, Guicheng!

Conclusion We would like to thank all contributors who have participated in Google Summer of Code 2026 with us! Your contributions helped make Rust better, and introduced you as new members of our community, which is a reason to celebrate. We are looking forward to participating in GSoC again next year!

We would also like to thank Google for organizing the Google Summer of Code program and for allowing us to host a large number of projects every year. And last, but not least, we would like to thank all the Rust mentors who were tirelessly helping our contributors to complete their projects. Without you, Rust GSoC would not be possible.

97.5% over a three-year period, if you are wondering (40 out of 41 projects were successful so far). ↩ 97.5% over a three-year period, if you are wondering (40 out of 41 projects were successful so far).

↩ If you were wondering, then yes, this is actually related to the famous 2038 problem :) ↩ If you were wondering, then yes, this is actually related to the famous 2038 problem :) ↩ In case you were wondering, the mold linker does not support linker scripts required to link Linux kernel modules at the moment, so Vishruth did not compare the performance of Wild against mold here.

↩ In case you were wondering, the mold linker does not support linker scripts required to link Linux kernel modules at the moment, so Vishruth did not compare the performance of Wild against mold here. ↩