The Rust Foundation

Mentors: Student: cloud_0310@outlook.com

Historically, rustup has relied on $RUSTUP_HOME (defaulting to $HOME/.rustup) and $CARGO_HOME (defaulting to $HOME/.cargo) as monolithic directories for configuration, state, and data. In coordination with the Cargo team, this proposal aims to migrate `rustup` to use the standardized XDG Base Directory Specification on Linux. To achieve this safely, we will transition from a "dual-directory" approach to a "fine-grained" directory approach, unblock Cargo's own XDG migration, and establish a strict backward-compatibility protocol for existing installations.

Mentors: Student: Ryosuke Yamano

In Rust, trait visibility currently implies implementability. If a trait is visible within a given scope, it can also be implemented in that same scope. However, we do not always want everyone to be able to implement it. To address this, the so-called “sealed trait” pattern is used, which allows a trait to be used while restricting its implementation. This is typically achieved by defining a public trait in a private module. Similarly, field visibility implies mutability. However, we do not always want readable fields to be writable as well. As a result, developers often use private fields together with public getter methods. The Restrictions RFC extends the Rust syntax to be able to explicitly restrict the implementability of traits and mutability of fields. For example, `pub(super) impl(self) trait Trait {}` means that `Trait` can be used within the parent module, while its implementation is restricted to the current module. `pub(super) struct Struct { pub mut(self) field: u8 }` means that `Struct.field` is readable within the parent module, while its mutation is restricted to the current module. These impl and mut restrictions are optional. Although the RFC was accepted in 2022, implementation efforts have stalled. Our goal for this project is to implement both impl and mut restrictions in the Rust compiler.

Mentors: Student: Kei Akiyama

This project aims to add WebAssembly support to the Wild linker. Wild linker is a high-performance Linux linker written in Rust, and supporting the WebAssembly format would expand its applicability to even more Rust development scenarios. While LLVM's wasm-ld (lld) is currently the primary linker used for WebAssembly, Wild achieves link speeds that are often several times faster than lld for ELF linking across many scenarios, including mold, which was previously considered the fastest Linux linker. Since the fundamental linking process remains largely the same when adding WebAssembly support, much of the performance-critical implementation could be reused. Achieving similar performance gains for WebAssembly would therefore significantly reduce build times for Rust projects.

Mentors: Student: xonx4l

The std::arch in the standard library provides architecture-specific intrinsic functions, which directly map to a single machine instruction. The ultimate goal is to inline stdarch into rustc completely and archive the stdarch repository making stdarch tests reliable and maintainable inside rustc infrastructure. Which we will achieve by incrementally investigating the CI test suite of stdarch and port as much of it into rust-lang/rust. The clear set of deliverables for this project are Map stdarch CI to rustc, land x.py steps for verify + stdarch tests, enable core_arch (plain then assert_instr on Linux), port intrinsic-test in phases (host, then cross if feasible), minimal stdarch-gen checks, wire CI, document, final report.

Mentors: Student: zedddie

Currently there is obsolete `tests/ui/issues`directory in `rustc` test suite which was used to store regression tests in it. Now with the growth of compiler this folder is basically unmanageable, test names don't explain object of testing, and they are not sorted in any way. Nowadays new regression tests are getting into the fitting `tests/ui/`subdir, and my project proposes reorganization of `tests/ui/issues` directory by observing and sorting each test to matching directory.