├── README.md └── gsoc ├── README.md ├── proposal-guide.md └── runs ├── 2024.md └── 2025.md /README.md: -------------------------------------------------------------------------------- 1 | # Rust project ideas 2 | This page contains a list of ideas for various projects that could help improve 3 | the Rust Project and potentially also the wider Rust community. 4 | 5 | These project ideas can be used as inspiration for various OSS contribution programs, 6 | such as [Google Summer of Code](https://summerofcode.withgoogle.com/) or [OSPP](https://summer-ospp.ac.cn/). 7 | 8 | This document contains ideas that should still be actual. Here you can also find a list of projects from GSoC runs: 9 | 10 | - Google Summer of Code projects 11 | - [2025](gsoc/runs/2025.md) 12 | - [2024](gsoc/runs/2024.md) 13 | 14 | We invite contributors that would like to participate in projects such as GSoC or that would just want to find a Rust project that they would like to work on to examine the project list and use it as an inspiration. Another source of inspiration can be the [Rust Project Goals](https://rust-lang.github.io/rust-project-goals/index.html), particularly the orphaned goals. However, you can also work on these projects outside GSoC or other similar projects! We welcome all contributions. 15 | 16 | If you would like to participate in GSoC, please read [this](gsoc/README.md). 17 | If you would like to discuss projects ideas or anything related to them, you can do so on our [Zulip](https://rust-lang.zulipchat.com/). 18 | 19 | We use the GSoC project size parameters for estimating the expected time complexity of the project ideas. The individual project sizes have the following expected amounts of hours: 20 | - Small: 90 hours 21 | - Medium: 175 hours 22 | - Large: 350 hours 23 | 24 | ## Index 25 | - **Rust Compiler** 26 | - [Reproducible builds](#reproducible-builds) 27 | - [Refactoring of rustc_codegen_ssa to make it more convenient for the GCC codegen](#Refactoring-of-rustc_codegen_ssa-to-make-it-more-convenient-for-the-GCC-codegen) 28 | - [C codegen backend for rustc](#C-codegen-backend-for-rustc) 29 | - **Infrastructure** 30 | - [Port `std::arch` test suite to `rust-lang/rust`](#port-stdarch-test-suite-to-rust-langrust) 31 | - **Cargo** 32 | - [Move cargo shell completions to Rust](#move-cargo-shell-completions-to-Rust) 33 | - **Crate ecosystem** 34 | - [Add more lints to `cargo-semver-checks`](#add-more-lints-to-cargo-semver-checks) 35 | 36 | # Project ideas 37 | The list of ideas is divided into several categories. 38 | 39 | ## Rust Compiler 40 | 41 | ### Reproducible builds 42 | 43 | **Description** 44 | 45 | Recent OSS attacks such as the [XZ backdoor](https://en.wikipedia.org/wiki/XZ_Utils_backdoor) 46 | have shown the importance of having reproducible builds. 47 | 48 | Currently, the Rust toolchain distributed to Rust developers is not very reproducible. 49 | Our source code archives should be reproducible as of [this pull request](https://github.com/rust-lang/rust/pull/123246), 50 | however making the actual binary artifacts reproducible is a much more difficult effort. 51 | 52 | The goal of this project is to investigate what exactly makes Rust builds not reproducible, 53 | and try to resolve as many such issues as possible. 54 | 55 | While the main motivation is to make the Rust toolchain (compiler, standard library, etc.) releases 56 | reproducible, any improvements on this front should benefit the reproducibility of all Rust programs. 57 | 58 | See [Tracking Issue for Reproducible Build bugs and challenges](https://github.com/rust-lang/rust/issues/129080) 59 | for a non-exhaustive list of reproducibility challenges. 60 | 61 | **Expected result** 62 | 63 | Rust builds are more reproducible, ideally the Rust toolchain can be compiled in a reproducible manner. 64 | 65 | **Desirable skills** 66 | 67 | Knowledge of Rust and ideally also build systems. 68 | 69 | **Project size** 70 | 71 | Medium. 72 | 73 | **Difficulty** 74 | 75 | Hard. 76 | 77 | **Mentor** 78 | - Jakub Beránek ([GitHub](https://github.com/kobzol), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/266526-Jakub-Ber%C3%A1nek)) 79 | 80 | **Zulip streams** 81 | - [Idea discussion](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Idea.3A.20reproducible.20builds) 82 | 83 | **Related links** 84 | - [Prior art in Go](https://go.dev/blog/rebuild) 85 | 86 | ### Refactoring of `rustc_codegen_ssa` to make it more convenient for the GCC codegen 87 | 88 | **Description** 89 | 90 | [`rustc_codegen_gcc`](https://github.com/rust-lang/rustc_codegen_gcc) uses [`rustc_codegen_ssa`](https://rustc-dev-guide.rust-lang.org/backend/backend-agnostic.html) and implements the traits in this crate in order to have a codegen that plugs in `rustc` seamlessly. 91 | Since `rustc_codegen_ssa` was created based on `rustc_codegen_llvm`, they are somewhat similar, which sometimes makes it awkward for the GCC codegen. 92 | Indeed, some hacks were needed to be able to implement the GCC codegen with this API: 93 | 94 | * Usage of unsafe `transmute`: for instance, [this](https://github.com/rust-lang/rustc_codegen_gcc/blob/8037b6139fea50894978509744f00484150e6816/src/context.rs#L322) or [this](https://github.com/rust-lang/rustc_codegen_gcc/blob/8037b6139fea50894978509744f00484150e6816/src/context.rs#L412). Fixing this might require separating [`Value`](https://github.com/antoyo/rust/blob/c074d8eee765cfd64e6e143d2894c85c7f3ddc1d/compiler/rustc_codegen_ssa/src/traits/backend.rs#L24) into `RValue` and `LValue` or using [`Function`](https://github.com/antoyo/rust/blob/c074d8eee765cfd64e6e143d2894c85c7f3ddc1d/compiler/rustc_codegen_ssa/src/traits/backend.rs#L26) in place of `Value` in some places to better fit the GCC API. 95 | * Usage of mappings to workaround the API: for instance, [this](https://github.com/rust-lang/rustc_codegen_gcc/blob/8037b6139fea50894978509744f00484150e6816/src/context.rs#L123-L128) or [this](https://github.com/rust-lang/rustc_codegen_gcc/blob/8037b6139fea50894978509744f00484150e6816/src/context.rs#L95-L99). 96 | 97 | Some other improvement ideas include: 98 | 99 | * Separate the aggregate operations (structs, arrays): methods like [`extract_value`](https://github.com/rust-lang/rustc_codegen_gcc/blob/8037b6139fea50894978509744f00484150e6816/src/builder.rs#L1423) are generic over structures and arrays because it's the same operation in LLVM, but it is different operations in GCC, so it might make sense to have multiple methods like `extract_field` and `extract_array_element`. 100 | * Remove duplications between `rustc_codegen_gcc` and `rustc_codegen_llvm` by moving more stuff into `rustc_codegen_ssa`. For instance: 101 | * [some debuginfo code is exactly the same](https://github.com/rust-lang/rustc_codegen_gcc/blob/8037b6139fea50894978509744f00484150e6816/src/debuginfo.rs#L63) 102 | * [ABI code](https://github.com/rust-lang/rustc_codegen_gcc/blob/8037b6139fea50894978509744f00484150e6816/src/intrinsic/mod.rs#L509-L569) 103 | * [the allocator code](https://github.com/rust-lang/rustc_codegen_gcc/blob/8037b6139fea50894978509744f00484150e6816/src/allocator.rs#L16-L91) 104 | * [the dummy output type for inline assembly](https://github.com/rust-lang/rustc_codegen_gcc/blob/8037b6139fea50894978509744f00484150e6816/src/asm.rs#L704-L793) 105 | * perhaps we could add a `set_alignment` method in `rustc_codegen_ssa` that asks the backend to set the alignment and is called in `rustc_codegen_ssa` in strategic places so that we don't have to worry as much about alignment in the codegens (not sure if this is possible). 106 | 107 | The goal of this project is to improve `rustc_codegen_gcc` by removing hacks, unnecessary unsafe code and/or code duplication with `rustc_codegen_llvm` by refactoring `rustc_codegen_ssa`. 108 | It would be important that this refactoring does not result in a performance degradation for `rustc_codegen_llvm`. 109 | 110 | **Expected result** 111 | 112 | A `rustc_codegen_gcc` that contains less hacks, unsafe code and/or code duplication with `rustc_codegen_llvm`. 113 | 114 | **Desirable skills** 115 | 116 | Knowledge of Rust and basic knowledge of `rustc` internals, especially the [codegen part](https://rustc-dev-guide.rust-lang.org/backend/backend-agnostic.html). 117 | 118 | **Project size** 119 | 120 | Small-Medium depending on the chosen scope. 121 | 122 | **Difficulty** 123 | 124 | Medium. 125 | 126 | **Mentor** 127 | - Antoni Boucher ([GitHub](https://github.com/antoyo), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/404242-antoyo)) 128 | 129 | **Zulip streams** 130 | - [Idea discussion](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Idea.3A.20Refactoring.20of.20.60rustc_codegen_ssa.60.20for.20cg_gcc) 131 | - [rustc_codegen_gcc](https://rust-lang.zulipchat.com/#narrow/channel/386786-rustc-codegen-gcc/) 132 | 133 | ### C codegen backend for `rustc` 134 | 135 | **Description** 136 | 137 | `rustc` currently has three in-tree codegen backends: LLVM (the default), Cranelift, and GCC. 138 | These live at , as `rustc_codegen_*` crates. 139 | 140 | The goal of this project is to add a new experimental `rustc_codegen_c` backend that could turn Rust's internal 141 | representations into `C` code (i.e. transpile) and optionally invoke a `C` compiler to build it. This will allow Rust 142 | to use benefits of existing `C` compilers (better platform support, optimizations) in situations where the existing backends 143 | cannot be used. 144 | 145 | **Expected result** 146 | 147 | The minimum viable product is to turn `rustc` data structures that represent a Rust program into `C` code, and write the 148 | output to the location specified by `--out-dir`. This involves figuring out how to produce buildable `C` code from the 149 | inputs provided by `rustc_codegen_ssa::traits::CodegenBackend`. 150 | 151 | A second step is to have `rustc` invoke a `C` compiler on these produced files. This should be designed in a pluggable way, 152 | such that any `C` compiler can be dropped in. 153 | 154 | **Desirable skills** 155 | 156 | Knowledge of Rust and `C`, basic familiarity with compiler functionality. 157 | 158 | **Project size** 159 | 160 | Large. 161 | 162 | **Difficulty** 163 | 164 | Hard. 165 | 166 | **Mentor** 167 | - Trevor Gross ([GitHub](https://github.com/tgross35), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/532317-Trevor-Gross)) 168 | 169 | **Zulip streams** 170 | - [Idea discussion](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc/topic/Idea.3A.20C.20codegen.20backend.20for.20.60rustc.60) 171 | - [Compiler team](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler) 172 | - [Previous discussion about this topic](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/rustc_codegen_c) 173 | 174 | ## Infrastructure 175 | 176 | ### Port `std::arch` test suite to `rust-lang/rust` 177 | 178 | **Description** 179 | 180 | The [`std::arch`](https://doc.rust-lang.org/nightly/std/arch/index.html) module in the standard library provides architecture-specific intrinsic functions, which typically directly map to a single machine instruction. 181 | 182 | Currently, it lives in its own [repository](https://github.com/rust-lang/stdarch) outside the main [Rust compiler repository](https://github.com/rust-lang/rust) (`rustc`). The `rustc` repository includes `stdarch` only as a submodule, and does not execute its testsuite on the compiler's CI. This sometimes causes contributor friction, because updates to the compiler can break `stdarch` (and vice versa) and it is not possible to change both the compiler and `stdarch` at once (in the same pull request). 183 | 184 | `stdarch` has a comprehensive test suite that tests the intrinsics on several hardware architectures and operating system platforms, and it also includes fuzz tests. It cannot be simply copied over to `rustc`, because that has its own (much more complex) set of CI workflows. The `stdarch` testsuite thus has to be adapted to the way workflows are executed in the compiler repository. 185 | 186 | The ultimate goal is to inline `stdarch` into `rustc` completely, and archive the `stdarch` repository. This can be incrementally achieved by the following two steps: 187 | 188 | 1) Investigate the CI (continuous integration) test suite of `stdarch`, and port as much of it into `rustc`. This will involve implementing new testing and documentation steps for working with `stdarch` in the compiler's build system, [bootstrap](https://rustc-dev-guide.rust-lang.org/building/bootstrapping/how-bootstrap-does-it.html). 189 | 2) Once a sufficient portion of the test suite has been ported, `stdarch` should be changed from a submodule to either a git or [Josh](https://josh-project.github.io/josh) subtree, so that compiler contributors are able to make changes to `stdarch` when they modify the compiler. This might involve creating some automation tooling to help with performing regular synchronizations from/to `stdarch`. See [this page](https://rustc-dev-guide.rust-lang.org/external-repos.html#using-external-repositories) for more details. 190 | 191 | **Expected result** 192 | 193 | The most important parts of the `stdarch` test suite should be running in the CI of the Rust compiler. Ideally, `stdarch` should be included as a git/Josh subtree instead of a submodule, or in the best possible scenario moved completely into `rust-lang/rust`. 194 | 195 | **Desirable skills** 196 | 197 | Intermediate knowledge of Rust. Experience with GitHub Actions or CI workflows is a benefit. 198 | 199 | **Project size** 200 | 201 | Small to Medium. 202 | 203 | **Difficulty** 204 | 205 | Medium. 206 | 207 | **Mentors** 208 | - Jakub Beránek ([GitHub](https://github.com/kobzol), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/266526-Jakub-Ber%C3%A1nek)) 209 | 210 | **Zulip streams** 211 | - [Idea discussion](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Idea.3A.20Port.20.60std.3A.3Aarch.60.20test.20suite.20to.20.60rust-lang.2Frust.60) 212 | - [t-libs/stdarch](https://rust-lang.zulipchat.com/#narrow/channel/208962-t-libs.2Fstdarch) 213 | 214 | ## Cargo 215 | 216 | ### Move cargo shell completions to Rust 217 | 218 | **Description** 219 | 220 | Cargo maintains Bash and Zsh completions, but they are duplicated and limited in features. 221 | 222 | A previous GSoC participant added unstable support for completions in Cargo itself, 223 | so we can have a single implementation with per-shell skins ([rust-lang/cargo#6645](https://github.com/rust-lang/cargo/issues/6645)). 224 | - [**Final project report**](https://hackmd.io/@PthRWaPvSmS_2Yu_GLbGpg/Hk-ficKpC) 225 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2024/projects/jjnidpgn) 226 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc/topic/Project.3A.20Move.20cargo.20shell.20completions.20to.20Rust) 227 | 228 | There are many more arguments that need custom completers as well as polish in the completion system itself before this can be stabilized. 229 | 230 | See 231 | - [Clap's tracking issue](https://github.com/clap-rs/clap/issues/3166) 232 | - [Cargo's tracking issue](https://github.com/rust-lang/cargo/issues/14520) 233 | 234 | **Expected result** 235 | 236 | Ideal: 237 | - A report to clap maintainers on the state of the unstable completions and why its ready for stabilization 238 | - A report to cargo maintainers on the state of the unstable completions and why its ready for stabilization 239 | 240 | **Desirable skills** 241 | 242 | Intermediate knowledge of Rust. Shell familiarity is a bonus. 243 | 244 | **Project size** 245 | 246 | Medium. 247 | 248 | **Difficulty** 249 | 250 | Medium. 251 | 252 | **Mentor** 253 | - Ed Page ([GitHub](https://github.com/epage), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/424212-Ed-Page)) 254 | 255 | **Zulip streams** 256 | - [Idea discussion](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Idea.3A.20move.20cargo.20shell.20completions.20to.20Rust) 257 | 258 | ## Crate ecosystem 259 | 260 | ### Add more lints to `cargo-semver-checks` 261 | 262 | **Description** 263 | 264 | [`cargo-semver-checks`](https://github.com/obi1kenobi/cargo-semver-checks) is a linter for semantic versioning. It ensures 265 | that Rust crates adhere to semantic versioning by looking for breaking changes in APIs. 266 | 267 | It can currently catch ~120 different kinds of breaking changes, meaning there are hundreds of kinds of breaking changes it 268 | still cannot catch! The goal of this project is to extend its abilities, so that it can catch and prevent more breaking changes, by: 269 | - adding more lints, which are expressed as queries over a database-like schema ([playground](https://play.predr.ag/rustdoc)) 270 | - extending the schema, so more Rust functionality is made available for linting 271 | 272 | **Expected result** 273 | 274 | `cargo-semver-checks` will contain new lints, together with test cases that both ensure the lint triggers when expected 275 | and does not trigger in situations where it shouldn't (AKA false-positives). 276 | 277 | **Desirable skills** 278 | 279 | Intermediate knowledge of Rust. Familiarity with databases, query engines, or query language design is welcome but 280 | not required. 281 | 282 | **Project size** 283 | 284 | Medium or large, depends on how many lints will be implemented. The more lints, the better! 285 | 286 | **Difficulty** 287 | 288 | Medium to high, depends on the choice of implemented lints or schema extensions. 289 | 290 | **Mentor** 291 | - Predrag Gruevski ([GitHub](https://github.com/obi1kenobi/), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/474284-Predrag-Gruevski-(he-him))) 292 | 293 | **Zulip streams** 294 | - [Idea discussion](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc/topic/Idea.3A.20add.20more.20lints.20to.20.60cargo-semver-checks.60) 295 | 296 | **Related Links** 297 | - [Playground where you can try querying Rust data](https://play.predr.ag/rustdoc) 298 | - [GitHub issues describing not-yet-implemented lints](https://github.com/obi1kenobi/cargo-semver-checks/issues?q=is%3Aissue+is%3Aopen+label%3AE-mentor+label%3AA-lint+) 299 | - [Opportunities to add new schema, enabling new lints](https://github.com/obi1kenobi/cargo-semver-checks/issues/241) 300 | - [Query engine adapter](https://github.com/obi1kenobi/trustfall-rustdoc-adapter) 301 | -------------------------------------------------------------------------------- /gsoc/README.md: -------------------------------------------------------------------------------- 1 | # Google Summer of Code 2 | The Rust Project has decided to join the Google Summer of Code (GSoC) program for the first time in 2024. 3 | 4 | Runs: 5 | - **2025** (currently active): [accepted projects](runs/2025.md), [blog post announcement](https://blog.rust-lang.org/2025/05/08/gsoc-2025-selected-projects). 6 | - **2024**: [accepted projects](runs/2024.md), [blog post announcement](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html), [results](https://blog.rust-lang.org/2024/11/07/gsoc-2024-results.html). 7 | 8 | If you would like to participate in GSoC, please take a look at the [proposal guide](proposal-guide.md), which should help you prepare your GSoC proposals. 9 | 10 | **Please do not harrass and/or spam Rust Project members and mentors, or other members of the Rust community! If you do so, we will not consider your proposal. It is fine to send a direct message (DM) to a mentor that you want to communicate with, but do not spam multiple people with DMs, asking them to be a mentor for your project proposal! Post a topic in some Zulip stream instead.** 11 | 12 | The Rust Project can provide remote access to powerful cloud-based [Linux machines](https://forge.rust-lang.org/infra/docs/dev-desktop.html) to contributors that will be accepted for a GSoC Rust project. This can help overcome potential contribution barriers caused e.g. by an unsupported operating system or not performant enough hardware. 13 | -------------------------------------------------------------------------------- /gsoc/proposal-guide.md: -------------------------------------------------------------------------------- 1 | # Project proposal guidance 2 | 3 | This document contains a short guide on how to structure your Rust Google Summer of Code (GSoC) project proposal and how to increase the chance of your project proposal being accepted. 4 | 5 | **We would appreciate if you used your own words when writing GSoC project proposals. It is fine to use LLMs/AI for spellcheck, language correction or translation, but do not rely on AI to write the proposal for you. We will ignore proposals that look like they were *generated* by AI. Please don't submit AI-generated proposals! They won't be accepted, and will just create additional work for us.** 6 | 7 | **We're interested in seeing *your work* and *your thinking*, since *you* are applying to do the project — not the AI!** 8 | 9 | ## Choosing a project 10 | 11 | You should start by deciding on which project do you want to work on. You can use our [list of project ideas](../README.md) 12 | as an inspiration, or you can come up with your own project idea. However, you should keep in mind that each GSoC project needs at least one mentor available. Therefore, if you come up with a completely new project idea, you should also try to find someone from the Rust community who could mentor you on the project. 13 | 14 | If you decide to propose your own project idea, you're most likely to be able to find a mentor if one or both of these is true: 15 | - It aligns with existing open or planned work within the Project. For example, there are a number of [tracking issues](https://github.com/rust-lang/rust/issues?page=29&q=is%3Aissue+is%3Aopen+label%3AC-tracking-issue) and [Project Goals](https://rust-lang.github.io/rust-project-goals/index.html) for ongoing work. 16 | - You can describe clearly the utility of the project to either the Rust language, the tooling, the Project itself, or to the community. 17 | 18 | We encourage you to think of your own interesting project ideas! There are plenty of things that can be done within the Rust Project and contributors are generally happy to discuss and help you narrow down your thoughts into a concrete proposal. Don't be shy! 19 | 20 | ## Interacting with the Rust community 21 | 22 | If you want to discuss our suggested project ideas or your own idea, you can do so on the Rust Zulip. We have a dedicated 23 | [#gsoc](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc) stream for this that you can use. Either try to find a Zulip topic that already discusses the project idea that you are interested in, or create a new topic about your idea (`Start new conversation` -> Enter `Topic` name -> Write the initial message of the topic). You can use this Zulip stream to ask mentors about the project ideas. Make sure to listen to the feedback of the mentors, and try to incorporate it in your project proposal. 24 | 25 | The Rust Project also has three [organization admins](https://developers.google.com/open-source/gsoc/help/responsibilities) whose goal is to facilitate the communication of potential GSoC contributors and the mentors, and to manage the administration of the GSoC projects: 26 | - Jakub Beránek ([GitHub](https://github.com/Kobzol), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/266526-Jakub-Ber%C3%A1nek)) 27 | - Jack Huey ([GitHub](https://github.com/jackh726), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/232957-Jack-Huey)) 28 | - Paul Lenz ([Zulip](https://rust-lang.zulipchat.com/#narrow/dm/522542-Paul-Lenz)) 29 | 30 | When communicating on the Rust Zulip (and when interacting with the Rust community in general), please remember to be polite and uphold the [Rust Code of Conduct](https://www.rust-lang.org/policies/code-of-conduct). Keep in mind that most Rust contributors (and GSoC Rust project mentors) are volunteers, and work on Rust in their free time, so please treat them with respect and avoid spamming. 31 | 32 | ## Creating the project proposal 33 | 34 | Ultimately, the project proposal is the main deciding factor on whether your project will be accepted or not, so make sure that you put energy into making it as good as possible. 35 | 36 | The proposal should contain (at least) the following things: 37 | 1) A descriptive title of the project that you want to work on 38 | - Use the same title in the proposal PDF as what you enter in the GSoC dashboard! 39 | 2) Information about yourself, including: 40 | - Description of your programming experience, attained education, university and study programme that you're currently studying, etc. (a short CV would be ideal) 41 | - Link to a portfolio of projects that you have worked on (e.g. a GitHub profile or a personal website) 42 | - Your knowledge of Rust, since most projects will probably require at least some Rust knowledge 43 | - Your existing open-source contribution experience. If you have already contributed to some open-source repositories, make sure to include a link to these contributions in your proposal! 44 | - Your preferred time zone (for communicating with the mentor(s)) 45 | - Contact information, especially e-mail address. Use the same e-mail address in the proposal PDF as the one you enter in the GSoC dashboard/the one with which you logged into GSoC. 46 | 3) **Information about your proposed project**. This should be as detailed as possible, see more details [below](#project-information-and-timeline). 47 | 4) Information about other commitments that might affect your ability to work on the project during the GSoC period. These can include vacations, exams, other jobs or internships etc. It's not necessarily an issue to have other commitments, but it would be great to know about them in advance, if possible. 48 | 49 | ## Project information and timeline 50 | 51 | This is the most important part of your project proposal. You should include an abstract that explains your project in one or two paragraphs, and then a very detailed description that explains what exactly do you want to achieve in the proposed project. The proposal should also clearly state the designated mentor(s) for your project (you should get in touch with them before submitting the proposal). 52 | 53 | In addition to describing what do you intend to work on in the project, you should also specify the size of the project, according to the GSoC [documentation](https://google.github.io/gsocguides/student/time-management-for-students): 54 | - Small: ~90 hours 55 | - Medium: ~175 hours 56 | - Large: ~350 hours 57 | 58 | You should also create an approximate weekly plan of work and a list of deliverables. Recall that the default project duration is 12 weeks, but it can be [extended](https://google.github.io/gsocguides/student/time-management-for-students) (for medium and large projects) by up to 22 weeks. 59 | 60 | - Describe a brief outline of the work that you plan to do, and try to estimate how will the work be split in the individual weeks of the project. 61 | - Define milestones that you intend to achieve in specific weeks (e.g. finish X in week 4, deliver Y in the middle of the project, have a final version prepared one week before the end of the project, etc.). 62 | - You should focus specifically on the midterm point (week 6), because your mentor(s) will evaluate your progress at this time. You should be slightly more than half done at this moment, and have something reasonable to show. 63 | - In week 11 (one week before the end of the project), you should consider doing a "code freeze", and spend the last week to polish tests and documentation. 64 | 65 | Of course, it is quite difficult to predict this timeline exactly in advance, and it is not a problem to modify it while the project runs, but try to guesstimate it to the best of your ability. 66 | 67 | Furthermore, let us know what is your intended time commitment for working on the project. How many hours per day can you work on it? Are there specific days of the week when you can work on it? Is there some period of time from May to August where you know in advance that you won't be able to work on it? Please include this information in the proposal. 68 | 69 | There is a [Community bonding](https://google.github.io/gsocguides/student/how-gsoc-works) period before the contributors start working on their projects. It is designed to help you learn about the community that you're going to contribute to, and to start familiarizing yourself with the code and/or technology of your project. Please include a short description of preparatory work that you intend to work on during this community bonding period (should your project be accepted). 70 | 71 | ## How to increase your chance of being accepted? 72 | 73 | You can demonstrate your dedication (and ability) to work on the selected project proposal by contributing something related to it before your proposal is evaluated. This can encompass e.g. sending a pull request to the relevant repository, fixing a bug, writing documentation, etc. There is no specific template for these kinds of contributions, and it might not be possible to do for all types of projects. You can coordinate with the project mentors to find out if they can suggest some entry-level task for you. 74 | 75 | You can also tell us more about your motivation in your proposal. Why did you choose Rust for a GSoC project specifically? Do you like the Rust language? Is the specific project that you want to work on sympathetic to you for some reason? We would like to know! 76 | 77 | ## Don't forget to submit! 78 | 79 | You will need to submit your project proposal through the [Google Summer of Code](https://summerofcode.withgoogle.com/) website. Please keep the **deadline** (**8th April 2025**) in mind, as there will be no extensions! 80 | 81 | Good luck! :) 82 | 83 | ## How to decrease your chance of being accepted? 84 | 85 | There are some actions and behaviours that will make it much less likely that your application will be considered, so you should avoid these. For example: 86 | 87 | - Spamming or harassing mentors or other members of the Rust community. 88 | - Letting AI automatically generate your project proposal (you should put effort in it, don't be lazy!). 89 | - Suggesting unreasonably grandiose project proposals, e.g. adding a garbage collector to Rust. The [RFC process](https://github.com/rust-lang/rfcs) should be used for suggesting large changes to Rust. 90 | - Suggesting unreasonably trivial project proposals, e.g. fixing a typo in the Rust documentation. Remember that even the smallest [project size](https://google.github.io/gsocguides/student/time-management-for-students) should take about 90 hours! 91 | 92 | > This guide was inspired by https://github.com/python-gsoc/python-gsoc.github.io/blob/main/ApplicationTemplate.md. 93 | -------------------------------------------------------------------------------- /gsoc/runs/2024.md: -------------------------------------------------------------------------------- 1 | # Google Summer of Code 2024 2 | This page contains information about the `9` projects that were 3 | [accepted](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html) 4 | into [Google Summer of Code 2024](https://summerofcode.withgoogle.com/programs/2024/projects) 5 | under the Rust Project organization. 6 | 7 | ## Index 8 | - [Allow customizing lint levels and reporting in `cargo-semver-checks`](#allow-customizing-lint-levels-and-reporting-in-cargo-semver-checks) 9 | - [Fast(er) register allocator for Cranelift](#Faster-register-allocator-for-Cranelift) 10 | - [Improve Rust benchmark suite](#Improve-Rust-benchmark-suite) 11 | - [Move cargo shell completions to Rust](#Move-cargo-shell-completions-to-Rust) 12 | - [Rewriting Esoteric, Error-Prone Makefile Tests Using Robust Rust Features](#rewriting-esoteric-error-prone-makefile-tests-using-robust-rust-features) 13 | - [Rewriting the Rewrite trait](#rewriting-the-rewrite-trait) 14 | - [Rust to .NET compiler - add support for compiling & running cargo tests](#rust-to-net-compiler---add-support-for-compiling--running-cargo-tests) 15 | - [Sandboxed and Deterministic Proc Macro using Wasm](#sandboxed-and-deterministic-proc-macro-using-wasm) 16 | - [Tokio async support in Miri](#tokio-async-support-in-miri) 17 | 18 | ### Allow customizing lint levels and reporting in `cargo-semver-checks` 19 | 20 | This project was implemented by [Max Carr](https://github.com/suaviloquence/). 21 | 22 | - [**Final project report**](https://blog.mcarr.one/gsoc-final/) 23 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2024/projects/hADSyIDV) 24 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc/topic/Project.3A.20Adding.20lint.20configuration.20to.20cargo-semver-checks) 25 | 26 | **Description** 27 | 28 | [`cargo-semver-checks`](https://github.com/obi1kenobi/cargo-semver-checks) is a linter for semantic versioning. It ensures 29 | that Rust crates adhere to semantic versioning by looking for breaking changes in APIs. 30 | 31 | Currently, semver lints have a hardcoded level (e.g. breaking changes are "major") and are always reported at a "deny" 32 | level: if the release being scanned is a minor version bump, any lints at "major" level are reported as errors. 33 | 34 | This can be insufficient for some projects, which may desire to: 35 | - configure some lints to have a different level — e.g. turn a semver "major" lint into a "minor" lint, or vice versa 36 | - turn some lints into warnings instead of hard errorrs — reporting level "warn" instead of the default "deny" 37 | - disable some lints altogether by setting their reporting to "allow" 38 | - (stretch goal) allow customizing lint levels and reporting on a per-module basis 39 | 40 | Having such functionality would allow `cargo-semver-checks` to ship additional lints that target changes whose semver 41 | implications are defined by project maintainers on a per-project basis. An example of such a change is bumping the 42 | minimum supported Rust version (MSRV) of a project — some projects consider it a semver-major change, whereas for 43 | others it is minor or patch. 44 | 45 | This functionality would also allow us to write lints similar to clippy's ["suspicious" lint group](https://doc.rust-lang.org/nightly/clippy/lints.html#suspicious), 46 | flagging code that is suspect (and deserving of closer scrutiny) but possibly still correct. Such lints should be 47 | opt-in / "warn" tier to avoid annoying users, which is something this project would enable us to do. 48 | 49 | **Expected result** 50 | 51 | `cargo-semver-checks` lints will be configurable via the [`package.metadata`](https://doc.rust-lang.org/cargo/reference/manifest.html#the-metadata-table) table in `Cargo.toml` 52 | using a clear, simple and expressive way. The design will be suitable for both single-crate projects and workspaces. 53 | 54 | **Desirable skills** 55 | 56 | Intermediate knowledge of Rust. 57 | 58 | **Project size** 59 | 60 | Large. 61 | 62 | **Difficulty** 63 | 64 | Medium. 65 | 66 | **Mentor** 67 | - Predrag Gruevski ([GitHub](https://github.com/obi1kenobi/), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/474284-Predrag-Gruevski-(he-him))) 68 | 69 | **Related links** 70 | - [GitHub issue](https://github.com/obi1kenobi/cargo-semver-checks/issues/537) 71 | 72 | ### Fast(er) register allocator for Cranelift 73 | 74 | This project was implemented by [Demilade Sonuga](https://github.com/d-sonuga). 75 | 76 | - [**Final project report**](https://d-sonuga.netlify.app/gsoc/regalloc-iii/) 77 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2024/projects/zxxeGZMt) 78 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc/topic/Project.3A.20Faster.20Register.20Allocator.20For.20Cranelift) 79 | 80 | **Description** 81 | 82 | The Rust compiler uses various codegen backends to generate executable code (LLVM, GCC, Cranelift). 83 | The Cranelift backend should provide very quick compile times, however its performance is currently 84 | relatively bottlenecked by its register allocator. 85 | 86 | The goal of this project is to implement a new register allocator for Cranelift, that would be tuned for very 87 | quick compilation times (rather than optimal runtime performance of the compiled program). A first attempt could 88 | simply create an allocator that spills all registers to stack, and a possible follow-up could be a linear scan allocator. 89 | It would be useful to compare the compilation vs runtime performance trade-offs of various register allocation approaches. 90 | 91 | **Expected result** 92 | 93 | It will be possible to use a new register allocator in Cranelift that will work at least for simple programs and that 94 | will improve Rust compilation times. 95 | 96 | **Desirable skills** 97 | 98 | Intermediate knowledge of Rust. Basic knowledge of assembly. Familiarity with compiler technologies is a bonus. 99 | 100 | **Project size** 101 | 102 | Medium. 103 | 104 | **Difficulty** 105 | 106 | Medium. 107 | 108 | **Mentors** 109 | - Amanieu d'Antras ([GitHub](https://github.com/Amanieu), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/143274-Amanieu)) 110 | - Chris Fallin ([GitHub](https://github.com/cfallin), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/327027-Chris-Fallin)) 111 | 112 | ### Improve Rust benchmark suite 113 | 114 | This project was implemented by [s7tya](https://github.com/s7tya). 115 | 116 | - [**Final project report**](https://gist.github.com/s7tya/96dc1cae4ca9e59841a95f0f48d023d6) 117 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2024/projects/MeyNanKI) 118 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc/topic/Project.3A.20Improve.20Rust.20benchmark.20suite) 119 | 120 | **Description** 121 | 122 | Rust has an extensive [benchmark suite](https://github.com/rust-lang/rustc-perf) that measures the performance of the Rust compiler and Rust programs and 123 | visualizes the results in an interactive web application. It received a lot of new features in the past few years, however 124 | some of them are not as polished as they could be. 125 | 126 | The goal of this project is to improve both the frontend website and its various dashboards, and also profiling and analysis 127 | tools used to examine benchmarks in the suite. As an example, improvements could be made in the following areas: 128 | - Runtime benchmarks. The suite recently got support for runtime benchmarks that measure the performance of Rust programs 129 | compiled by a specific version of `rustc` (the Rust compiler). There is a lot of features that could be added to get 130 | runtime benchmarks to the same support level as compile-time benchmarks, like adding and visualizing benchmark variance 131 | analysis for them or adding runtime benchmark results to various dashboards in the frontend. 132 | - Analysis of multithreaded performance. The Rust compiler has recently gained support for using multiple threads for its 133 | frontend, but there is no configuration in the suite to parametrize how many threads will be used, nor any analysis of 134 | how well are threads utilized. It would be nice to add analysis and visualisation for this. 135 | - Some pages of the website still use HTML templates. It would be great to port these to the Vue-based frontend. 136 | 137 | **Expected result** 138 | 139 | New analyses will be available in the Rust benchmark suite, and/or the suite website will contain more useful data and 140 | visualizations. 141 | 142 | **Desirable skills** 143 | 144 | Basic knowledge of Rust, intermediate knowledge of frontend web technologies (TypeScript, HTML, CSS, Vue). 145 | 146 | **Project size** 147 | 148 | Medium. 149 | 150 | **Difficulty** 151 | 152 | Medium. 153 | 154 | **Mentor** 155 | - Jakub Beránek ([GitHub](https://github.com/kobzol), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/266526-Jakub-Ber%C3%A1nek)) 156 | 157 | ### Move cargo shell completions to Rust 158 | 159 | This project was implemented by [Shanmu](https://github.com/shannmu). 160 | 161 | - [**Final project report**](https://hackmd.io/@PthRWaPvSmS_2Yu_GLbGpg/Hk-ficKpC) 162 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2024/projects/jjnidpgn) 163 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc/topic/Project.3A.20Move.20cargo.20shell.20completions.20to.20Rust) 164 | 165 | **Description** 166 | 167 | Cargo maintains Bash and Zsh completions, but they are duplicated and limited in features. 168 | We want to implement completions in Cargo itself, so we can have a single implementation with per-shell skins ([rust-lang/cargo#6645](https://github.com/rust-lang/cargo/issues/6645)). 169 | Most of the implementation will be in clap ([clap-rs/clap#3166](https://github.com/clap-rs/clap/issues/3166)), allowing many tools to benefit from this improvement. 170 | 171 | **Expected result** 172 | 173 | Cargo shell completion will be extended and implemented in Rust. 174 | This will allow access to easier to add new commands / arguments to commands, richer results, and easier testing. 175 | 176 | **Desirable skills** 177 | 178 | Intermediate knowledge of Rust. Shell familiarity is a bonus. 179 | 180 | **Project size** 181 | 182 | Medium. 183 | 184 | **Difficulty** 185 | 186 | Medium. 187 | 188 | **Mentor** 189 | - Ed Page ([GitHub](https://github.com/epage), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/424212-Ed-Page)) 190 | 191 | ### Rewriting Esoteric, Error-Prone Makefile Tests Using Robust Rust Features 192 | 193 | This project was implemented by [Julien Robert](https://github.com/Oneirical). 194 | 195 | - [**Final project report**](https://oneirical.github.io/gsocfinal/) 196 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2024/projects/P5BC91Hr) 197 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc/topic/Project.3A.20Rewriting.20Makefile.20Tests.20Using.20Rust) 198 | 199 | **Description** 200 | 201 | The Rust compiler currently uses a so-called `run-make` test suite for complex test scenarios that involve other tools (e.g. bash utilities, linkers, etc.) in addition to the compiler itself. As the name suggests, these tests are based on `make`, and they invoke various tools to test complex situations. 202 | 203 | However, this approach has a number of drawbacks: 204 | 205 | - Because the tests are based on commandline tools like `nm` and `grep`, test authors and reviewers have to know the syntax of these tools, which can be quite arcane and is often interleaved with Makefile's own syntax. 206 | - Tests are hard to read because they are based on commandline tool exit codes. 207 | - It is quite hard to write these tests in a cross-platform way, since each implementation often behaves slightly differently. This leads to various issues and workarounds, especially on non-Unix platforms. 208 | - In many cases, when a test fails, it is quite hard to find where exactly it failed. 209 | - It is quite easy to write a test that looks fine, but actually does not test anything (e.g. testing that certain text is not present in the output passes because a program silently fails to produce any output). 210 | 211 | The goal of this project is to replace these Makefile tests with a new test harness, where the tests would be written using regular Rust code. To support these tests, a support library should be implemented, which will be used by the tests to perform common actions, such as invoking the compiler, grepping files, checking symbols, finding tools, and providing readable error messages when a test fails. The support library can rely on commandline tools under the hood, but it should provide a nice Rust API that behaves the same on all platforms. The tests can be ported to the new framework one at a time, and the old Makefile framework can be removed once all tests are ported. 212 | 213 | There is currently already an open [PR](https://github.com/rust-lang/rust/pull/113026) that has initiated some of what is 214 | described here, however there is still a lot of follow-up work left to be done. 215 | 216 | **Expected result** 217 | 218 | `run-make` tests are replaced with an ergonomic and well-documented Rust-based test infrastructure. A fraction of the old 219 | `run-make` tests are ported to the new Rust-based test infrastructure. 220 | 221 | **Desirable skills** 222 | 223 | Intermediate knowledge of Rust. 224 | 225 | Familiarity with standard bash utilities and their behavior preferred (e.g. `grep`, `nm` and others). 226 | 227 | **Project size** 228 | 229 | Large. 230 | 231 | **Difficulty** 232 | 233 | Medium. 234 | 235 | **Mentors** 236 | - Jieyou Xu ([GitHub](https://github.com/jieyouxu), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/259697-Jieyou-Xu)) 237 | 238 | **Related links** 239 | - [PR with initial test infrastructure](https://github.com/rust-lang/rust/pull/113026) 240 | 241 | ### Rewriting the Rewrite trait 242 | 243 | This project was implemented by [SeoYoung Lee](https://github.com/ding-young). 244 | 245 | - [**Final project report**](https://ding-young.github.io/posts/gsoc-final/) 246 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2024/projects/gHEu3vxc) 247 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc/topic/Project.3A.20Rewriting.20the.20Rewrite.20trait) 248 | 249 | **Description** 250 | 251 | The internal formatting mechanisms in rustfmt has issues tracking the context when issues occur when applying formatting. This can lead to silent failures and limit the ability for rustfmt to retry formatting. A potential solution would be to refactor the [`Rewrite`](https://doc.rust-lang.org/stable/nightly-rustc/rustfmt_nightly/rewrite/trait.Rewrite.html) trait, currently used to format various AST structures, which could improve how we handle situations where it failed to format. 252 | 253 | More details in the discussions linked below. 254 | 255 | **Expected result** 256 | 257 | Improved user experience with less silent failures (provide context as to how and why formatting failed) and allowing rustfmt to retry formatting under more contexts. 258 | 259 | **Desirable skills** 260 | 261 | Intermediate knowledge of Rust. Understanding of AST (Abstract Syntax Tree) structures are welcomed, but not required. 262 | 263 | **Project size** 264 | 265 | Medium. 266 | 267 | **Difficulty** 268 | 269 | Medium. 270 | 271 | **Mentor** 272 | - Yacin Tmimi ([GitHub](https://github.com/ytmimi), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/441976-Yacin-Tmimi)) 273 | 274 | **Related Links** 275 | - [Previous discussion around the idea #1](https://rust-lang.zulipchat.com/#narrow/stream/357797-t-rustfmt/topic/meeting.202023-05-22/near/3604084950) 276 | - [Previous discussion around the idea #2](https://rust-lang.zulipchat.com/#narrow/stream/357797-t-rustfmt/topic/meeting.202023-01-08/near/412181455) 277 | 278 | ### Rust to .NET compiler - add support for compiling & running cargo tests 279 | 280 | This project was implemented by [Fractal Fir](https://github.com/FractalFir). 281 | 282 | - [**Final project report**](https://fractalfir.github.io/generated_html/rustc_codegen_clr_v0_2_0.html) 283 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2024/projects/IIHP5ozV) 284 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc/topic/Project.3A.20Rust.20to.20.2ENET.20compiler) 285 | 286 | **Description** 287 | 288 | This project aims to extend the ability of [`rustc_codegen_clr`](https://github.com/FractalFir/rustc_codegen_clr), the Rust to .NET compiler backend, to run `cargo test`s. 289 | While the project is already quite feature-rich, it still can't compile Rust tests properly. This project will focus on adding all the features necessary for such tests to run, with the end goal of running them within the .NET runtime. Adding those features will not only enable running tests, it will also improve the project, enabling it to compile far more Rust programs. 290 | 291 | At the end of GSoC, this project will deliver the following features: 292 | 1) Support for parsing command line arguments in Rust programs running within the .NET runtime. 293 | 2) Implementation of atomic intrinsics needed for `std` argument parsing to function properly. They should be implemented using cross-platform .NET APIs, but using architecture-specific functions may be needed to properly handle certain atomics. 294 | 3) Support for dynamic trait objects - creating them, dropping them, calling their member functions. 295 | 4) Support for catching panics, implemented using the .NET exception-handling primitives. 296 | 5) Support for multithreading: launching threads, and getting information about them. 297 | 6) Extended .NET interop, automatic creation of safe GC handles for managed objects. This feature is necessary for safely handling .NET threads, but will be exposed in the `mycorrhiza` interop layer, provided by the codegen. 298 | 7) Fixes to string formatting. This feature is necessary for reporting test results. At the end of this proposal, simple formatting, such as `format!("my string is:{string}")` should run within the .NET runtime. The end goal of this proposal is running a simple cargo test within the .NET runtime. This test will consist of two cases: one failing, and one passing. All the deliverables mentioned above are strictly needed for achieving that goal. 299 | 300 | **Expected result** 301 | 302 | The .NET Rust codegen backend will be able to run Rust tests and potentially even the Rust compiler test suite. 303 | 304 | **Desirable skills** 305 | 306 | Intermediate knowledge of Rust and .NET. 307 | 308 | **Project size** 309 | 310 | Large. 311 | 312 | **Difficulty** 313 | 314 | Medium. 315 | 316 | **Mentor** 317 | - Jack Huey ([GitHub](https://github.com/jackh726), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/232957-Jack-Huey)) 318 | 319 | ### Sandboxed and Deterministic Proc Macro using Wasm 320 | 321 | This project was implemented by [Apurva Mishra](https://github.com/mav3ri3k). 322 | 323 | - [**Final project report**](https://github.com/mav3ri3k/rust/blob/gsoc24/gsoc24.md) 324 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2024/projects/kXG0mZoj) 325 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc/topic/Project.3A.20Sandboxed.20and.20Deterministic.20Proc.20Macro.20using.20Wasm) 326 | 327 | **Description** 328 | 329 | Add experimental support to rustc for building and running procedural macros as WebAssembly. Procedural Macro crates can opt in for being compiled to WebAssembly. This wasm-proc-macro will be a wasm blob sandboxed using WASM. It will interact with the compiler only through a stream of token and no ability to interact with the outside world. 330 | 331 | **Expected result** 332 | 333 | Proof of concept of proc macros that are compiled to WebAssembly, integrated within rustc. 334 | 335 | **Desirable skills** 336 | 337 | Intermediate knowledge of Rust. 338 | 339 | **Project size** 340 | 341 | Medium. 342 | 343 | **Difficulty** 344 | 345 | Large. 346 | 347 | **Mentor** 348 | - David Lattimore ([GitHub](https://github.com/davidlattimore), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/198560-David-Lattimore)) 349 | 350 | ### Tokio async support in Miri 351 | 352 | This project was implemented by [Tiffany Pek Yuan](https://github.com/tiif). 353 | 354 | - [**Final project report**](https://gist.github.com/tiif/3e08ba6e8cfb1d078e6155410108ae48) 355 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2024/projects/rk1Ey4hN) 356 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc/topic/Project.3A.20Tokio.20async.20support.20in.20Miri) 357 | 358 | **Description** 359 | 360 | [Miri](https://github.com/rust-lang/miri) is a testing tool to check undefined behaviour in unsafe Rust. Currently, a significant portion of Tokio async program still cannot be effectively tested with Miri due to unhandled system calls. This project aims to rectify this limitation by offering support for Tokio async in Miri through a complete implementation of epoll shim. By doing so, it will open up a whole new part of the async ecosystem to be tested with Miri, ensuring greater reliability and stability in Rust ecosystem. 361 | 362 | **Expected result** 363 | 364 | Ability to support programs with `epoll` and similar syscalls in Miri. 365 | 366 | **Desirable skills** 367 | 368 | Intermediate knowledge of Rust. 369 | 370 | **Project size** 371 | 372 | Large. 373 | 374 | **Difficulty** 375 | 376 | Medium. 377 | 378 | **Mentor** 379 | - Oli Scherer ([GitHub](https://github.com/oli-obk), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/124288-oli)) 380 | -------------------------------------------------------------------------------- /gsoc/runs/2025.md: -------------------------------------------------------------------------------- 1 | # Google Summer of Code 2025 2 | This page contains information about the `19` projects that were 3 | [accepted](https://blog.rust-lang.org/2025/05/08/gsoc-2025-selected-projects) 4 | into [Google Summer of Code 2025](https://summerofcode.withgoogle.com/programs/2025/projects) 5 | under the Rust Project organization. 6 | 7 | Google Summer of Code 2025 is currently in progress, it is expected to conclude in Autumn 2025. After that we will post the results on the [Rust blog](https://blog.rust-lang.org/) and also here. 8 | 9 | ## Index 10 | 11 | *Note that the projects are displayed in alphabetical order.* 12 | 13 | - [ABI/Layout handling for the automatic differentiation feature](#abilayout-handling-for-the-automatic-differentiation-feature) 14 | - [Add safety contracts](#add-safety-contracts) 15 | - [Bootstrap of rustc with `rustc_codegen_gcc`](#bootstrap-of-rustc-with-rustc_codegen_gcc) 16 | - [Cargo: Build script delegation](#cargo-build-script-delegation) 17 | - [Distributed and resource-efficient verification](#distributed-and-resource-efficient-verification) 18 | - [Enable Witness Generation in `cargo-semver-checks`](#enable-witness-generation-in-cargo-semver-checks) 19 | - [Extend behavioural testing of `std::arch` intrinsics](#extend-behavioural-testing-of-stdarch-intrinsics) 20 | - [Implement merge functionality in bors](#implement-merge-functionality-in-bors) 21 | - [Improve bootstrap](#improve-bootstrap) 22 | - [Improve Wild linker test suites](#improve-wild-linker-test-suites) 23 | - [Improving the Rustc Parallel Frontend: Parallel Macro Expansion](#improving-the-rustc-parallel-frontend-parallel-macro-expansion) 24 | - [Make `cargo-semver-checks` faster](#make-cargo-semver-checks-faster) 25 | - [Make Rustup Concurrent](#make-rustup-concurrent) 26 | - [Mapping the Maze of Rust's UI Test Suite with Established Continuous Integration Practices](#mapping-the-maze-of-rusts-ui-test-suite-with-established-continuous-integration-practices) 27 | - [Modernising the libc Crate](#modernising-the-libc-crate) 28 | - [New proc-macro Server API for Rust-Analyzer](#new-proc-macro-server-api-for-rust-analyzer) 29 | - [Prepare `stable_mir` crate for publishing](#prepare-stable_mir-crate-for-publishing) 30 | - [Prototype an alternative architecture for `cargo fix` using `cargo check`](#prototype-an-alternative-architecture-for-cargo-fix-using-cargo-check) 31 | - [Prototype Cargo Plumbing Commands](#prototype-cargo-plumbing-commands) 32 | 33 | ## Projects 34 | 35 | ### ABI/Layout handling for the automatic differentiation feature 36 | 37 | This project is being implemented by [Marcelo Domínguez](https://github.com/sa4dus). 38 | 39 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/USQvru7i) 40 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20ABI.2FLayout.20handling.20for.20autodiff/with/516963958) 41 | 42 | **Description** 43 | 44 | Over the last year, support for automatic differentiation ('autodiff') was added to the Rust compiler. The autodiff tool which we are using ([Enzyme](https://enzyme.mit.edu/)) operates 45 | on LLVM-IR, which is the intermediate representation of code, used by LLVM. LLVM is the default backend of the Rust compiler. Unfortunately, two layout related problems limit its usability. 46 | 47 | A) The Rust compiler has a set of ABI optimizations which can improve performance, but make it harder for autodiff to work. An example is the function `fn foo(a: f32, b: f32) -> f32`, 48 | which the compiler might optimize to `fn foo(x: i64) -> f32`. While this is fine from an LLVM perspective, it makes it hard for Enzyme, the LLVM based autodiff tool. 49 | More information about such optimizations can be found [here](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20Where.20do.20ABI.20.22changes.22.20happen.3F). 50 | If a function has a `#[rustc_autodiff]` attribute, the Rust compiler should simply not perform such optimizations. We don't want to disable these optimizations for all functions, as they are generally beneficial. 51 | Multiple examples of function headers which will get handled incorrectly at the moment are listed [here](https://github.com/EnzymeAD/rust/issues/105). 52 | 53 | B) Enzyme requires good information about the memory layout of types, both to be able to differentiate the code, and to do so efficiently. In order to help Enzyme, 54 | we want to lower more Type Information from MIR or even THIR into LLVM-IR metadata, or make better usage of existing debug info. If you are interested in this part and 55 | also have some LLVM experience, please have a look at the LLVM website for the related proposal. 56 | 57 | For both A) and B), the online compiler explorer [here](https://enzyme.mit.edu/explorer/) can be used to trigger both types of bugs, to get a feeling for existing problems. 58 | 59 | **Expected result** 60 | 61 | The Rust compiler should not perform ABI optimizations on functions with the `#[rustc_autodiff]` attribute. As a result, `#[autodiff(..)]` should be able to handle functions with almost arbitrary headers. If a general solution turns out tricky, it is ok to focus on the most common types like those listed in the issue above (e.g. combinations of floats, small arrays/structs/tuples, etc.). We care less about advanced types like those listed [here](https://doc.rust-lang.org/reference/special-types-and-traits.html). These changes can't have a performance impact on functions without the `#[rustc_autodiff]` attribute. 62 | 63 | Newly working testcases should be added to the rust test suite. The `rustc_autodiff` parsing in the [autodiff frontend](https://github.com/rust-lang/rust/pull/129458) might need small bugfixes if the new testcases discover additional bugs, but those can also be solved by other contributors. 64 | 65 | Examples for code that currently is not handled correctly can be discussed in the project proposal phase. 66 | 67 | **Project size** 68 | 69 | Medium. 70 | 71 | **Mentors** 72 | - Manuel Drehwald ([GitHub](https://github.com/zusez4), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/348574-Manuel-Drehwald)) 73 | - Oli ([GitHub](https://github.com/oli-obk), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/124288-oli)) 74 | 75 | **Related links** 76 | - [Automatic differentiation working group](https://rust-lang.zulipchat.com/#narrow/channel/390790-wg-autodiff) 77 | 78 | ### Add safety contracts 79 | 80 | This project is being implemented by [Dawid Lachowicz](https://github.com/dawidl022). 81 | 82 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/UYWEKUkd) 83 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Add.20safety.20contracts/with/516964153) 84 | 85 | **Description** 86 | 87 | There is a Rust project goal to 88 | [instrument the Rust standard library with safety contracts](https://rust-lang.github.io/rust-project-goals/2025h1/std-contracts.html). 89 | With this approach we are moving from informal comments specifying safety requirements on `unsafe` functions to executable Rust code. To prioritize which functions to equip with contracts first, we run a verification contest in the 90 | [verify-rust-std](https://github.com/model-checking/verify-rust-std) fork. In this contest, [challenges](https://model-checking.github.io/verify-rust-std/challenges.html) 91 | have been put up that request specific sets of functions to be equipped with 92 | contracts. We also welcome new challenges being proposed by anyone, or contracts being 93 | contributed outside any of the existing challenges. 94 | 95 | For example, we are currently looking for contributions towards the following challenges: 96 | - [Verify the memory safety of core intrinsics using raw pointers](https://model-checking.github.io/verify-rust-std/challenges/0002-intrinsics-memory.html) 97 | - [Memory safety of BTreeMap's `btree::node` module](https://model-checking.github.io/verify-rust-std/challenges/0004-btree-node.html) 98 | - [Safety of Methods for Atomic Types & Atomic Intrinsics](https://model-checking.github.io/verify-rust-std/challenges/0007-atomic-types.html) 99 | - [Contracts for SmallSort](https://model-checking.github.io/verify-rust-std/challenges/0008-smallsort.html) 100 | - [Safety of `NonZero`](https://model-checking.github.io/verify-rust-std/challenges/0012-nonzero.html) 101 | 102 | There is, however, no restriction to contribute to just those challenges: any of 103 | the other open challenges are equally of interest, and so is creating new 104 | challenges. 105 | 106 | **Expected result** 107 | 108 | A set of safety contracts and harnesses have been implemented in 109 | [verify-rust-std](https://github.com/model-checking/verify-rust-std) for one of 110 | the open challenges or any newly created challenge. 111 | A stretch goal is to port upstream as many of those contracts as possible. 112 | 113 | **Project size** 114 | 115 | Large. 116 | 117 | **Mentor** 118 | - Michael Tautschnig ([GitHub](https://github.com/tautschnig), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/887765-Michael-Tautschnig)) 119 | 120 | ### Bootstrap of rustc with `rustc_codegen_gcc` 121 | 122 | This project is being implemented by [Michał Kostrubiec](https://github.com/FractalFir). 123 | 124 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/KmfCY0i6) 125 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Bootstrap.20of.20rustc.20with.20rustc_codegen_gcc/with/516964245) 126 | 127 | **Description** 128 | 129 | [`rustc_codegen_gcc`](https://github.com/rust-lang/rustc_codegen_gcc) [used to be able to compile `rustc`](https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-10) and use the resulting compiler to successfully compile a `Hello, World!` program. 130 | While it can still compile a [stage 2](https://rustc-dev-guide.rust-lang.org/building/bootstrapping/what-bootstrapping-does.html#stage-2-the-truly-current-compiler) `rustc`, the resulting compiler cannot compile the standard library anymore. 131 | 132 | The goal of this project would be to fix in `rustc_codegen_gcc` any issue preventing the resulting compiler to compile a `Hello, World!` program and the standard library. 133 | Those issues are not known, so the participant would need to attempt to do a bootstrap and investigate the issues that arises. 134 | 135 | If time allows, an optional additional goal could be to be able to do a full bootstrap of `rustc` with `rustc_codegen_gcc`, meaning fixing even more issues to achieve this result. 136 | 137 | **Expected result** 138 | 139 | A `rustc_codegen_gcc` that can compile a stage 2 `rustc` where the resulting compiler can compile a `Hello, World!` program using the standard library (also compiled by that resulting compiler). 140 | 141 | An optional additional goal would be: a `rustc_codegen_gcc` that can do a full bootstrap of the Rust compiler. This means getting a stage 3 `rustc` that is identical to stage 2. 142 | 143 | **Project size** 144 | 145 | Large. 146 | 147 | **Mentor** 148 | - Antoni Boucher ([GitHub](https://github.com/antoyo), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/404242-antoyo)) 149 | 150 | **Related links** 151 | - [rustc_codegen_gcc](https://rust-lang.zulipchat.com/#narrow/channel/386786-rustc-codegen-gcc/) 152 | 153 | ### Cargo: Build script delegation 154 | 155 | This project is being implemented by [Naman Garg](https://github.com/namanlp). 156 | 157 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/nUt4PdAA) 158 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Cargo.3A.20Build.20script.20delegation/with/516964379) 159 | 160 | **Description** 161 | 162 | When developers need to extend how Cargo builds their package, 163 | they can write a [build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html). 164 | This gives users quite a bit of flexibility but 165 | - Allows running arbitrary code on the users system, requiring extra auditing 166 | - Needs to be compiled and run before the relevant package can be built 167 | - They are all-or-nothing, requiring users to do extra checks to avoid running expensive logic 168 | - They run counter to the principles of third-party build tools that try to mimic Cargo 169 | 170 | A developer could make their build script a thin wrapper around a library 171 | (e.g. [shadow-rs](https://crates.io/crates/shadow-rs)) 172 | but a build script still exists to be audited (even if its small) and each individual wrapper build script must be compiled and linked. 173 | This is still opaque to third-party build tools. 174 | 175 | Leveraging an unstable feature, 176 | [artifact dependencies](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#artifact-dependencies), 177 | we could allow a developer to say that one or more dependencies should be run as build scripts, passing parameters to them. 178 | 179 | This project would add unstable support for build script delegation that can 180 | then be evaluated for proposing as an RFC for approval. 181 | 182 | See [the proposal](https://github.com/rust-lang/cargo/issues/14903#issuecomment-2523803041) for more details. 183 | 184 | **Expected result** 185 | 186 | Milestones 187 | 1. An unstable feature for multiple build scripts 188 | 2. An unstable feature for passing parameters to build scripts from `Cargo.toml`, built on the above 189 | 3. An unstable feature for build script delegation, built on the above two 190 | 191 | Bonus: preparation work to stabilize a subset of artifact dependencies. 192 | 193 | **Project size** 194 | 195 | Large. 196 | 197 | **Mentor** 198 | - Ed Page ([GitHub](https://github.com/epage), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/424212-Ed-Page)) 199 | 200 | ### Distributed and resource-efficient verification 201 | 202 | This project is being implemented by [Zhou Jiping](https://github.com/zjp-CN). 203 | 204 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/5677hd6S) 205 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Distributed.20and.20resource-efficient.20verification/with/516964679) 206 | 207 | **Description** 208 | 209 | We have taken a goal to 210 | [instrument the Rust standard library with safety contracts](https://rust-lang.github.io/rust-project-goals/2025h1/std-contracts.html). 211 | With this approach we are moving from informal comments specifying safety 212 | requirements on `unsafe` functions to executable Rust code. 213 | To prove that these safety requirements hold in all possible executions we need 214 | to run static analysis tools. 215 | We would further like to prove that these safety requirements continue to hold 216 | despite code changes. 217 | Therefore, we will want to run static analysis tools that prove these safety 218 | requirements in continuous integration. 219 | We have started such an effort in our 220 | [verify-rust-std](https://github.com/model-checking/verify-rust-std) fork. 221 | 222 | Static analysis tools will typically require compute effort that may go up to 223 | minutes per function that needs to be proved. 224 | With a growing number of contracts we will, therefore, need to distribute proof 225 | effort across multiple nodes. 226 | We may, however, also _reduce_ the proof effort when we can identify that any 227 | given proof necessarily continues to hold as the transitive closure of functions 228 | governed by the contract has not been modified since the proof last completed. 229 | 230 | We are looking for contributions in the following areas: 231 | 1. A reachability- or impact analysis that, given a code change, determines 232 | which proofs require re-verification. This will avoid wasting compute 233 | resources for unnecessary re-verification. 234 | 2. A system that will shard proofs across multiple nodes and recombine their 235 | results. Multiple verification tools may be involved, and tools may have 236 | varying performance characteristics. Load balancing could conceivably be done 237 | in a dynamic fashion (where communication between nodes is required, but this 238 | may be hard to accomplish with GitHub runners), or per a pre-computed 239 | distribution (mapping pre-defined sets of verification tasks to runners). In 240 | the latter (and likely more feasible) scenario the distribution should be 241 | easy to adjust via configuration files for we expect the set of verification 242 | tasks to change over time. 243 | 244 | **Expected result** 245 | 246 | A system that can reliably run all verification tasks within a time limit (where 247 | that time limit needs to be determined empirically), and for changes that do not 248 | impact any contract no actual verification tool is invoked. 249 | 250 | **Project size** 251 | 252 | Medium. 253 | 254 | **Mentor** 255 | - Michael Tautschnig ([GitHub](https://github.com/tautschnig), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/887765-Michael-Tautschnig)) 256 | 257 | ### Enable Witness Generation in `cargo-semver-checks` 258 | 259 | This project is being implemented by [Talyn Veugelers](https://github.com/GlitchlessCode). 260 | 261 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/MMRSG9WU) 262 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Enable.20Witness.20Generation.20in.20cargo-semver-checks/with/516964780) 263 | 264 | **Description** 265 | 266 | When `cargo-semver-checks` reports a breaking change, it in principle has seen enough information for the breakage to be reproduced with an example program: a *witness* program. 267 | Witness programs are valuable as they confirm that the suspected breakage did indeed happen, and is not a false-positive. 268 | 269 | **Expected result** 270 | 271 | Automatic witness generation is something we've explored, but we've only scratched the surface at implementing it so far. 272 | The goal of this project would be to take it the rest of the way: enable `cargo-semver-checks` to (with the user's opt-in) generate witness programs for each lint, verify that they indeed demonstrate the detected breakage, and inform the user appropriately of the breakage and the manner in which it was confirmed. 273 | If a witness program *fails* to reproduce breakage flagged by one of our lints, we've found a bug — the tool should then prepare a diagnostic info packet and offer to help the user open an auto-populated GitHub issue. 274 | 275 | **Stretch goal:** having implemented witness generation, run another study of SemVer compliance in the Rust ecosystem, similar to [the study we completed in 2023](https://predr.ag/blog/semver-violations-are-common-better-tooling-is-the-answer/). The new study would cover many more kinds of breaking changes, since `cargo-semver-checks` today has 2.5x times more lints than it did back then. It would also reveal any new false-positive issues, crashes, or other regressions that may have snuck into the tool in the intervening years. 276 | 277 | **Project size** 278 | 279 | Large. 280 | 281 | **Mentor** 282 | - Predrag Gruevski ([GitHub](https://github.com/obi1kenobi/), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/474284-Predrag-Gruevski-(he-him))) 283 | 284 | **Related Links** 285 | - [Playground where you can try querying Rust data](https://play.predr.ag/rustdoc) 286 | - [Use of witness programs to verify breaking change lints](https://predr.ag/blog/semver-violations-are-common-better-tooling-is-the-answer/#automated-validation-via-witnesses) 287 | 288 | ### Extend behavioural testing of `std::arch` intrinsics 289 | 290 | This project is being implemented by [Madhav Madhusoodanan](https://github.com/madhav-madhusoodanan). 291 | 292 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/DeMQAjwi) 293 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Extend.20behavioural.20testing.20of.20std.3A.3Aarch.20intrinsics/with/516964868) 294 | 295 | **Description** 296 | 297 | The [`std::arch`](https://doc.rust-lang.org/nightly/std/arch/index.html) module in the standard library provides architecture-specific intrinsic functions, which typically directly map to a single machine instruction. 298 | 299 | These intrinsics are based on the architecture-specific intrinsics in C, which are usually based on a vendor specification and then implemented by C compilers such as Clang or GCC. 300 | 301 | Rust supports thousands of intrinsics and we need to verify that they match the behavior of the equivalent intrinsics in C. A first step towards this has been the [`intrinsic-test`](https://github.com/rust-lang/stdarch/tree/master/crates/intrinsic-test) which fuzz tests the ARM (AArch32 and AArch64) intrinsics by generating C and Rust programs which call the intrinsics with random data and then verifying that the output is the same in both programs. 302 | 303 | While this covers the ARM architectures, we have thousands of intrinsics for other architectures (notably x86) which are only lightly tested with manual tests. The goal of this project is to extend `intrinsic-test` to other architectures: x86, PowerPC, LoongArch, etc. 304 | 305 | **Expected result** 306 | 307 | By the end of this project `intrinsic-test` should be able to validate the behavior of intrinsics on multiple architectures. The primary goal is to support x86 since this is the most widely used architecture, but stretch goals could include support for other architectures such as PowerPC, LoongArch, WebAssembly, etc. 308 | 309 | **Project size** 310 | 311 | Medium. 312 | 313 | **Mentors** 314 | - Amanieu d'Antras ([GitHub](https://github.com/Amanieu), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/143274-Amanieu-d'Antras)) 315 | 316 | **Related links** 317 | - [t-libs/stdarch](https://rust-lang.zulipchat.com/#narrow/channel/208962-t-libs.2Fstdarch) 318 | 319 | ### Implement merge functionality in bors 320 | 321 | This project is being implemented by [Sakibul Islam](https://github.com/Sakib25800). 322 | 323 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/HlR12jqX) 324 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Implement.20merge.20functionality.20in.20bors/with/516964988) 325 | 326 | **Description** 327 | 328 | Various Rust repositories under the [rust-lang](https://github.com/rust-lang) organization use a merge queue bot (bors) for testing and merging pull requests. Currently, we use a legacy implementation called [homu](https://github.com/rust-lang/homu), which is quite buggy and very difficult to maintain, so we would like to get rid of it. We have started the implementation of a new bot called simply [bors](https://github.com/rust-lang/bors), which should eventually become the primary method for merging pull requests in the [rust-lang/rust](https://github.com/rust-lang/rust) repository. 329 | 330 | The bors bot is a GitHub app that responds to user commands and performs various operations on a GitHub repository. Primarily, it creates merge commits and reports test workflow results for them. It can currently perform so-called "try builds", which can be started manually by users on a given PR to check if a subset of CI passed on the PR. However, the most important functionality, actually merging pull requests into the main branch, has not been implemented yet. 331 | 332 | **Expected result** 333 | 334 | bors can be used to perform pull request merges, including "rollups". In an ideal case, bors will be already usable on the `rust-lang/rust` repository. 335 | 336 | **Project size** 337 | 338 | Medium. 339 | 340 | **Mentor** 341 | - Jakub Beránek ([GitHub](https://github.com/kobzol), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/266526-Jakub-Ber%C3%A1nek)) 342 | 343 | **Related links** 344 | - [Infra team](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra) 345 | 346 | ### Improve bootstrap 347 | 348 | This project is being implemented by [Shourya Sharma](https://github.com/Shourya742). 349 | 350 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/2KNHAlKz) 351 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Improve.20bootstrap/with/516965103) 352 | 353 | **Description** 354 | 355 | The Rust compiler it bootstrapped using a complex set of scripts and programs generally called just `bootstrap`. 356 | This tooling is constantly changing, and it has accrued a lot of technical debt. It could be improved in many areas, for example: 357 | 358 | - Design a new testing infrastructure and write more tests. 359 | - Write documentation. 360 | - Remove unnecessary hacks. 361 | 362 | **Expected result** 363 | 364 | The `bootstrap` tooling will have less technical debt, more tests, and better documentation. 365 | 366 | **Project size** 367 | 368 | Medium. 369 | 370 | **Mentors** 371 | - Jakub Beránek ([GitHub](https://github.com/kobzol), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/266526-Jakub-Ber%C3%A1nek)) 372 | - Jieyou Xu ([GitHub](https://github.com/jieyouxu), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/259697-Jieyou-Xu)) 373 | - Onur Özkan ([GitHub](https://github.com/onur-ozkan), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/461362-Onur-(onur-ozkan))) 374 | 375 | **Related links** 376 | - [Bootstrap team](https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap) 377 | 378 | ### Improve Wild linker test suites 379 | 380 | This project is being implemented by [Kei Akiyama](https://github.com/lapla-cogito). 381 | 382 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/ps99Kaqk) 383 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Improve.20Wild.20linker.20test.20suites/with/516965324) 384 | 385 | **Description** 386 | 387 | The Wild linker is a project to build a very fast linker in Rust that has incremental linking and 388 | hot reload capabilities. 389 | 390 | It currently works well enough to link itself, the Rust compiler, clang (provided you use the right 391 | compiler flags) and a few other things. However, there are various features and combinations of 392 | flags that don’t yet work correctly. Furthermore, we have a pretty incomplete picture of what we 393 | don’t support. 394 | 395 | The proposed project is to run the test suite of other linkers with Wild as the linker being tested, 396 | then for each failure, determine what the problem is. It’s expected that many failures will have the 397 | same root cause. 398 | 399 | **Expected result** 400 | 401 | Write a program, ideally in Rust, that runs the test suite of some other linker. Mold’s test suite 402 | is pretty easy to run with Wild, so that’s probably a good default choice. The Rust program should 403 | emit a CSV file with one row per test, whether the test passes or fails and if it fails, an attempt 404 | to identify the cause based on errors / warnings emitted by Wild. 405 | 406 | For tests where Wild doesn’t currently emit any error or warning that is related to the cause of the 407 | test failure, attempt to make it do so. Some of the tests might fail for reasons that are hard to 408 | identify. It’s OK to just leave these as uncategorised. Where tests fail due to bugs or differences 409 | in behaviour of Wild, automatic classification likely isn’t practical. A one-off classification of 410 | these would be beneficial. 411 | 412 | If time permits, pick something achievable that seems like an important feature / bug to support / 413 | fix and implement / fix it. 414 | 415 | **Project size** 416 | 417 | Medium. 418 | 419 | **Mentor** 420 | - David Lattimore ([GitHub](https://github.com/davidlattimore), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/198560-David-Lattimore)) 421 | 422 | **Related links** 423 | - [Wild linker](https://github.com/davidlattimore/wild) 424 | - [Blog posts, most of which are about Wild](https://davidlattimore.github.io/) 425 | 426 | ### Improving the Rustc Parallel Frontend: Parallel Macro Expansion 427 | 428 | This project is being implemented by [Lorrens](https://github.com/LorrensP-2158466). 429 | 430 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/SBW3GMno) 431 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Improve.20Parallel.20Frontend.20Parallel.20Macro.20expansion/with/516965603) 432 | 433 | **Description** 434 | 435 | Improving compiler performance has always been a focus of the Rust community and one of the main tasks of the compiler team. [Parallelization](https://rustc-dev-guide.rust-lang.org/parallel-rustc.html) of rust compiler is an important and effective approach. 436 | Currently, the backend end (codegen part) of the compiler has been parallelized, which has brought a huge improvement in the performance of the compiler. However, there is still much room for improvement in the parallelization of the rust frontend. 437 | 438 | The most important and valuable work in this area are two aspects: 439 | 440 | A) Diagnosing and fixing deadlock [issues](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AWG-compiler-parallel+deadlock) caused by the execution order of compiler queries in a multithreaded environment. 441 | [Queries](https://rustc-dev-guide.rust-lang.org/query.html) is a unique design of the Rust compiler, which is used to achieve incremental compilation process. It divides the compiler 442 | process into various parts and caches the execution results of each part. However, queries caching dependencies between multiple threads may cause deadlock. 443 | [`Work-stealing`](https://en.wikipedia.org/wiki/Work_stealing), a method used to improve parallelization performance, is the core reason. 444 | 445 | To solve these problems, we need to find the part of the compiler process that causes deadlock through diagnosing coredumps in issues, and adjusting the execution order 446 | of this part of code so that there will be no circular dependencies on the query caches between multiple threads. This [PR](https://github.com/rust-lang/rust/pull/118488) is a good example of solving a deadlock problem. 447 | 448 | B) Improving the performance of the parallel frontend 449 | The parallel frontend has implemented parallelization in type checking, MIR borrow checking and other parts of the compiler. However, there is still a lot of room for improvement: 450 | - HIR lowering. Modifying the array structure of `tcx.untracked.definitions` so that it can be accessed efficiently in multiple threads is likely to be the key. 451 | - Macro expansion. How to deal with the order problem of name resolution during macro expansion is a difficult problem. 452 | - Lexing and/or parsing. 453 | 454 | Achieving the above goals is of big significance to improving the performance of the Rust compiler. 455 | 456 | The project could choose either one of these two areas, or try to tackle both of them together. 457 | 458 | **Expected result** 459 | 460 | Parallel frontend will not cause deadlock issues. We can ensure usability through [UI testing](https://github.com/rust-lang/rust/pull/132051). 461 | 462 | The performance of the compiler will be improved, ideally at least by a couple of percentage points. 463 | 464 | **Project size** 465 | 466 | Medium. 467 | 468 | **Mentor** 469 | - Sparrow Li ([GitHub](https://github.com/SparrowLii), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/353056-Sparrow-Li)) 470 | 471 | **Related links** 472 | - [Parallel frontend working group](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fwg-parallel-rustc) 473 | - [Parallel frontend project goal](https://rust-lang.github.io/rust-project-goals/2025h1/parallel-front-end.html) 474 | 475 | ### Make `cargo-semver-checks` faster 476 | 477 | This project is being implemented by [JosephC](https://github.com/CLIDragon). 478 | 479 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/qs2rDLG4) 480 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Make.20cargo-semver-checks.20faster/with/516965733) 481 | 482 | **Description** 483 | 484 | As more lints get added to [`cargo-semver-checks`](https://github.com/obi1kenobi/cargo-semver-checks), its runtime grows longer. 485 | As a result, users' iteration loops and CI pipelines take longer as well, degrading the overall experience of using the tool. 486 | 487 | Figure out ways to speed up `cargo-semver-checks`, and find good ways to deploy them without degrading the maintainability of the codebase! 488 | 489 | **Expected result** 490 | 491 | The wall-clock runtime of running `cargo-semver-checks` on a large Rust crate gets cut by 50-80%, while still running the same lints as before. 492 | 493 | **Project size** 494 | 495 | Large. 496 | 497 | **Mentor** 498 | - Predrag Gruevski ([GitHub](https://github.com/obi1kenobi/), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/474284-Predrag-Gruevski-(he-him))) 499 | 500 | **Related Links** 501 | - [Playground where you can try querying Rust data](https://play.predr.ag/rustdoc) 502 | - [Past optimization work: Speeding up Rust semver-checking by over 2000x](https://predr.ag/blog/speeding-up-rust-semver-checking-by-over-2000x/) 503 | - [Conference talk: How Database Tricks Sped up Rust Linting Over 2000x](https://www.youtube.com/watch?v=Fqo8r4bInsk) 504 | - [Query engine adapter, where many of the optimizations may be deployed](https://github.com/obi1kenobi/trustfall-rustdoc-adapter) 505 | 506 | ### Make Rustup Concurrent 507 | 508 | This project is being implemented by [Francisco Gouveia](https://github.com/FranciscoTGouveia). 509 | 510 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/CpXV4kzH) 511 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Make.20Rustup.20Concurrent/with/516965858) 512 | 513 | **Description** 514 | 515 | [rustup](https://github.com/rust-lang/rustup) is an indispensable part of Rust's infrastructure, as it provides easy access to a Rust toolchain to millions of Rust users. 516 | 517 | When installing a toolchain, it first downloads a set of components and then extracts them to disk. Currently, all downloads and disk I/O is performed serially, which makes rustup slower than it could be. Ideally, it should be able to overlap network downloads with disk I/O, and potentially also perform multiple network downloads at once. 518 | 519 | Making rustup faster could have a high impact on the Rust ecosystem, particularly in CI environments, where rustup is typically used to download a Rust toolchain in every workflow execution. Since there are tens of thousands of repositories that use Rust in their CI, this can add up quickly. 520 | 521 | There has been a prior [experiment](https://github.com/dtolnay/fast-rustup) that showed that concurrent rustup could in fact provide non-trivial performance improvements. [This issue](https://github.com/rust-lang/rustup/issues/731) contains discussion on the topic. 522 | 523 | The rustup codebase now uses `async`, which should make implementing concurrent network and disk operations simpler. 524 | 525 | The goal of the project is to add concurrency to rustup to enable overlap od network and disk I/O operations and perform benchmarks and experiments to evaluate what is the performance effect of such a change and when it is even worth it to perform it. 526 | 527 | **Expected result** 528 | 529 | Rustup will be able to overlap network and disk I/O and perform network requests concurrently. 530 | 531 | **Project size** 532 | 533 | Medium. 534 | 535 | **Mentor** 536 | - rami3l ([GitHub](https://github.com/rami3l), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/616990-rami3l)) 537 | 538 | **Related Links** 539 | - [Rustup discord channel](https://discord.com/channels/442252698964721669/463480252723888159) 540 | - [fast-rustup experiment](https://github.com/dtolnay/fast-rustup) 541 | - [Concurrent rustup GitHub issue](https://github.com/rust-lang/rustup/issues/731) 542 | 543 | ### Mapping the Maze of Rust's UI Test Suite with Established Continuous Integration Practices 544 | 545 | This project is being implemented by [Julien Robert](https://github.com/oneirical). 546 | 547 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/KP02lKL4) 548 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Mapping.20the.20Maze.20of.20Rust's.20UI.20Test.20Suite/with/516965989) 549 | 550 | **Description** 551 | 552 | The Rust compiler (`rustc`) relies on large suites of integration tests to check its behavior. One of such test suite is the `ui` test suite (see [tests/ui]). The `ui` test suite has more than 18000 tests, and continues to grow, so it's important that it has a good organization and usability so contributors can find a test (at all) or identify possible test coverage for some feature/behavior. 553 | 554 | However, there's a lot of tests in the `ui` test suite that suffer from suboptimal organization, naming and other kinds of deficiencies that make certain `ui` tests less effective than they could be. See [Tracking Issue for ui test suite improvements #133895][ui-tracking-issue] for common issues and potential improvement ideas. The goal of this project is to improve the `ui` test suite's organization and usability. 555 | 556 | The major challenge of this project is to identify how to *improve* certain `ui` tests *without regressing test intent*. 557 | 558 | **Expected result** 559 | 560 | Improved `ui` test suite organization and/or usability. Possible outcomes include but are not limited to: 561 | 562 | - Fewer top-level tests immediately under (`tests/ui/`), to be moved under more fitting subdirectories. 563 | - Some `ui` tests have improved test docs regarding test intention / references. 564 | - Some `ui` tests are adjusted to better serve their actual test intent. 565 | 566 | See the [tracking issue][ui-tracking-issue] for more detailed descriptions of what more effective `ui` tests *could* look like. 567 | 568 | **Project size** 569 | 570 | Large. 571 | 572 | **Mentor** 573 | - Jieyou Xu ([GitHub](https://github.com/jieyouxu), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/259697-Jieyou-Xu)) 574 | 575 | [tests/ui]: https://github.com/rust-lang/rust/tree/master/tests/ui 576 | [ui-tracking-issue]: https://github.com/rust-lang/rust/issues/133895 577 | 578 | ### Modernising the libc Crate 579 | 580 | This project is being implemented by [Abdul Muiz](https://github.com/mbyx). 581 | 582 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/r3LkZkOy) 583 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Modernising.20the.20libc.20Crate/with/516966121) 584 | 585 | **Description** 586 | 587 | The [libc](https://github.com/rust-lang/libc) crate is one of the oldest crates of the Rust ecosystem, long predating 588 | Rust 1.0. Additionally, it is one of the most widely used crates in the ecosystem (#4 most downloaded on crates.io). 589 | This combinations means that the current version of the libc crate (`v0.2`) is very conservative with breaking changes 590 | has accumulated a list of things to do in a 1.0 release. Additionally, some of the infrastructure for `lib` is rather 591 | outdated. 592 | 593 | Most of the changes required for 1.0 are under the [1.0 milestone](https://github.com/rust-lang/libc/milestone/1). Some 594 | of these come from the evolution of the underlying platforms, some come from a desire to use newer language features, 595 | while others are simple mistakes that we cannot correct without breaking existing code. 596 | 597 | The crate used for testing `libc` (`ctest`) uses an old syntax parser that cannot support modern Rust, so some of the 598 | changes will require rewriting `ctest` to use a newer parser (e.g. `syn`). This upgrade is tracked at 599 | https://github.com/rust-lang/libc/issues/4289. 600 | 601 | The goal of this project is to prepare and release the next major version of the libc crate. 602 | 603 | **Expected result** 604 | 605 | The libc crate is cleaned up and modernized, and released as version 0.3. 606 | 607 | **Project size** 608 | 609 | Medium. 610 | 611 | **Mentor** 612 | - Trevor Gross ([GitHub](https://github.com/tgross35), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/532317-Trevor-Gross)) 613 | 614 | **Related links** 615 | - [Library team](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs) 616 | 617 | ### New proc-macro Server API for Rust-Analyzer 618 | 619 | This project is being implemented by [Neil Wang](https://github.com/DriedYellowPeach). 620 | 621 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/76ekEjd1) 622 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20New.20proc-macro.20Server.20API.20for.20Rust-Analyzer/with/516966300) 623 | 624 | **Description** 625 | 626 | Today, rust-analyzer (and RustRover) expands proc-macros by spawning a separate proc-macro server 627 | process that loads and executes the proc-macro dynamic libraries. They communicate to this process 628 | via a JSON RPC interface that has not been given much thought when it was implemented, now starting 629 | to show its limitations. 630 | 631 | The goal is to replace this current implementation entirely in favor of a more performant format 632 | that also supports the more complicated needs of the proc-macro API, outlined in 633 | https://github.com/rust-lang/rust-analyzer/issues/19205. 634 | 635 | **Expected result** 636 | 637 | There exists a new proc-macro server that is more efficient and allows for implementing the 638 | remaining proc-macro API. Ideally, it should be integrated within rust-analyzer. 639 | 640 | **Project size** 641 | 642 | Medium. 643 | 644 | **Mentor** 645 | - Lukas Wirth ([GitHub](https://github.com/veykril), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/300586-Lukas-Wirth)) 646 | 647 | **Related links** 648 | - [rust-analyzer team](https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer) 649 | 650 | ### Prepare `stable_mir` crate for publishing 651 | 652 | This project is being implemented by [Makai](https://github.com/makai410). 653 | 654 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/3y9x5X8O) 655 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Prepare.20stable_mir.20crate.20for.20publishing/with/516966374) 656 | 657 | **Description** 658 | 659 | We are advancing the Rust compiler's StableMIR API, which provides a robust foundation for code analysis tool development. 660 | This API was specifically designed to shield developers from compiler internals, provide an intuitive interface, and to follow semantic versioning. 661 | 662 | The project currently spans two key crates: 663 | 1. `stable_mir`: The public-facing API for tool developers 664 | 2. `rustc_smir`: The internal bridge between `stable_mir` and the Rust compiler. 665 | 666 | As we prepare to [publish the `stable_mir` crate](https://rust-lang.github.io/rust-project-goals/2025h1/stable-mir.html), we are seeking contributions in these critical areas: 667 | 668 | 1. Refactor the dependency between `rustc_smir` and the `stable_mir` crates in the compiler to help us prepare for releasing `stable_mir` v0.1. More details of this refactoring can be found [here](https://hackmd.io/jBRkZLqAQL2EVgwIIeNMHg). 669 | 2. Implement a build time check on `stable-mir` crate to warn users that are using an unsupported version of the compiler. 670 | 3. Improve test coverage and automation including CI improvements to test with different compiler versions. 671 | 4. Create comprehensive developer documentation that covers maintenance procedures for both crates, ensuring future maintainers have clear guidelines for updates and compatibility management. 672 | 5. Continue the StableMIR integration with MiniRust to help us assess and improve StableMIR as described in [this issue](https://github.com/rust-lang/project-stable-mir/issues/66). 673 | 674 | **Expected result** 675 | 676 | We are able to publish an initial version of the `stable_mir` crate that works across multiple nightly versions, and that gracefully fails if the version is not supported. 677 | 678 | **Project size** 679 | 680 | Large. 681 | 682 | **Mentor** 683 | - Celina Val ([GitHub](https://github.com/celinval), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/442621-celinval)) 684 | 685 | **Related links** 686 | - [stable_mir](https://rust-lang.zulipchat.com/#narrow/channel/320896-project-stable-mir) 687 | 688 | ### Prototype an alternative architecture for `cargo fix` using `cargo check` 689 | 690 | This project is being implemented by [Glen Thalakottur](https://github.com/Pyr0de). 691 | 692 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/fBOCR2Sp) 693 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Prototype.20an.20alternative.20architecture.20for.20cargo.20fix/with/516966558) 694 | 695 | **Description** 696 | 697 | Some compiler errors know how to fix the problem and `cargo fix` is the command for applying those fixes. 698 | Currently, `cargo fix` calls into the APIs that implement `cargo check` with 699 | `cargo` in a way that allows getting the json messages from rustc and apply 700 | them to workspace members. 701 | To avoid problems with conflicting or redundant fixes, `cargo fix` runs `rustc` for workspace members in serial. 702 | As one fix might lead to another, `cargo fix` runs `rustc` for each workspace member in a loop until a fixed point is reached. 703 | This can be very slow for large workspaces. 704 | 705 | We want to explore an alternative architecture where `cargo fix` runs the 706 | `cargo check` command in a loop, 707 | processing the json messages, 708 | until a fixed point is reached. 709 | 710 | Benefits 711 | - Always runs in parallel 712 | - May make it easier to extend the behavior, like with an interactive mode 713 | 714 | Downsides 715 | - Might have issues with files owned by multiple packages or even multiple build targets 716 | 717 | This can leverage existing CLI and crate APIs of Cargo and can be developed as a third-party command. 718 | 719 | See [cargo#13214](https://github.com/rust-lang/cargo/issues/13214) for more details. 720 | 721 | **Expected result** 722 | 723 | - A third-party command as described above 724 | - A comparison of performance across representative crates 725 | - An analysis of corner the behavior with the described corner cases 726 | 727 | **Project size** 728 | 729 | Medium. 730 | 731 | **Mentor** 732 | - Ed Page ([GitHub](https://github.com/epage), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/424212-Ed-Page)) 733 | 734 | **Related links** 735 | - [Cargo team](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo) 736 | 737 | ### Prototype Cargo Plumbing Commands 738 | 739 | This project is being implemented by [Vito Secona](https://github.com/secona). 740 | 741 | - [GSoC project annotation](https://summerofcode.withgoogle.com/programs/2025/projects/fTDzc0sk) 742 | - [Project discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Prototype.20Cargo.20Plumbing.20Commands/with/516966661) 743 | 744 | **Description** 745 | 746 | Cargo is a high-level, opinionated command. 747 | Instead of trying to directly support every use case, 748 | we want to explore exposing the building blocks of the high-level commands as 749 | "plumbing" commands that people can use programmatically to compose together to 750 | create custom Cargo behavior. 751 | 752 | This can be prototyped outside of the Cargo code base, using the Cargo API. 753 | 754 | See the [Project Goal](https://rust-lang.github.io/rust-project-goals/2025h1/cargo-plumbing.html) for more details. 755 | 756 | **Expected result** 757 | 758 | Ideal: a performant `cargo porcelain check` command that calls out to 759 | individual `cargo plumbing ` commands to implement its functionality. 760 | 761 | Depending on the size the participant takes on and their experience, 762 | this may be out of reach. 763 | The priorities are: 764 | 1. A shell of `cargo porcelain check` 765 | 2. Individual commands until `cargo porcelain check` is functional 766 | 3. Performance 767 | 768 | **Project size** 769 | 770 | Medium. 771 | 772 | **Mentor** 773 | - Ed Page ([GitHub](https://github.com/epage), [Zulip](https://rust-lang.zulipchat.com/#narrow/dm/424212-Ed-Page)) 774 | 775 | **Related links** 776 | - [Cargo team](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo) 777 | --------------------------------------------------------------------------------