This page contains a list of ideas for various projects that could help improve the Rust Project and potentially also the wider Rust community.
These project ideas can be used as inspiration for various OSS contribution programs, such as Google Summer of Code or OSPP.
In the list below, you can find projects from past GSoC runs:
This README contains ideas that are actual for Google Summer of Code 2026.
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, particularly the orphaned goals. However, you can also work on these projects outside GSoC or other similar projects! We welcome all contributions.
If you would like to participate in GSoC, please read this, in particular the guidance around AI usage! If you would like to discuss project ideas or anything related to them, you can do so on our Zulip.
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:
- Small: 90 hours
- Medium: 175 hours
- Large: 350 hours
- Rust Compiler
- Infrastructure
- Cargo
- Rustup
- Crate ecosystem
- Rust Analyzer
- Rust Embedded
The list of ideas is divided into several categories.
Description
The Rust compiler debuginfo test suite should test how Rust programs interact with debuggers, such as GDB, LLDB and CDB. However, it is currently not fully exercised on CI, because it suffers from several issues:
- It is not easily possible to bless the expected output, which makes it quite difficult to maintain the test suite.
- It uses whatever version of a debugger is discovered (through inconsistent and varying means) on the system where the tests run.
- It does not allow specifying different expected outputs per different debugger versions.
- It is difficult (in part) to comprehend test failure, in part because debugger output is captured then fed to LLVM FileCheck, and the FileCheck failures in turn are hard to figure out what's wrong.
- There is a significant lack of docs surrounding the design intention and actual usage of the debuginfo test infra.
We would like to rewrite the test suite to make it more maintainable and thus increase our confidence in the Rust compiler debugger visualizers, and maintain the quality of debuginfo emitted (and detect if there are regressions).
Expected result
The Rust compiler debuginfo test suite is running fully on CI and is easier to maintain and bless.
A stretch goal is to also use the new debuginfo test suite to improve Rust debugger visualizers.
Desirable skills
Intermediate knowledge of Rust. Knowledge of debuggers and their APIs is a big plus.
Project size
Medium to large.
Difficulty
Hard.
Mentors
Zulip streams
Related links
TPDE is a compiler framework that can act as a LLVM backend with very high build performance. Since slow build times are a constant issue for Rust developers, we would like to experiment with a TPDE-based backend for rustc, to see how much faster could compilation times get.
There are essentially two approaches that could be chosen here. Either use the TPDE-LLVM LLVM backend to generate assembly from LLVM IR emitted by rustc, or create a completely separate rustc backend that will work on TPDE IR (intermediate representation) directly and avoid going through LLVM.
The TPDE-LLVM-based approach is preferred since it should achieve most of the performance benefits, allows reusing LLVM plugins and infrastructure where desired, and is more likely to succeed. However, we will consider both approaches if the applicant can make good arguments in favor of a completely separate TPDE backend.
Note that this would be experimental work that would most likely have to live out-of-tree, at least at the beginning of the project.
Expected result
We have a new rustc experimental backend that can be used to compile non-trivial Rust programs (it does not have to be complete though, e.g. inline assembly support will probably not make the cut), and we can evaluate its performance e.g. on the Rust Compiler Benchmark Suite.
Desirable skills
Knowledge of Rust, basic familiarity with compiler functionality or LLVM is a bonus.
Project size
Large.
Difficulty
Medium to hard.
Mentor
Zulip streams
Description
Recent OSS attacks such as the XZ backdoor have shown the importance of having reproducible builds.
Currently, the Rust toolchain distributed to Rust developers is not very reproducible. Our source code archives should be reproducible as of this pull request, however making the actual binary artifacts reproducible is a much more difficult effort.
The goal of this project is to investigate what exactly makes Rust builds not reproducible, and try to resolve as many such issues as possible.
While the main motivation is to make the Rust toolchain (compiler, standard library, etc.) releases reproducible, any improvements on this front should benefit the reproducibility of all Rust programs.
See Tracking Issue for Reproducible Build bugs and challenges for a non-exhaustive list of reproducibility challenges.
Expected result
Rust builds are more reproducible, ideally the Rust toolchain can be compiled in a reproducible manner.
Desirable skills
Knowledge of Rust and ideally also build systems.
Project size
Medium.
Difficulty
Hard.
Mentor
Zulip streams
Related links
Description
rustc_codegen_gcc uses rustc_codegen_ssa and implements the traits in this crate in order to have a codegen that plugs in rustc seamlessly.
Since rustc_codegen_ssa was created based on rustc_codegen_llvm, they are somewhat similar, which sometimes makes it awkward for the GCC codegen.
Indeed, some hacks were needed to be able to implement the GCC codegen with this API:
- Usage of unsafe
transmute: for instance, this or this. Fixing this might require separatingValueintoRValueandLValueor usingFunctionin place ofValuein some places to better fit the GCC API. - Usage of mappings to workaround the API: for instance, this or this.
Some other improvement ideas include:
- Separate the aggregate operations (structs, arrays): methods like
extract_valueare 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 likeextract_fieldandextract_array_element. - Remove duplications between
rustc_codegen_gccandrustc_codegen_llvmby moving more stuff intorustc_codegen_ssa. For instance:- some debuginfo code is exactly the same
- ABI code
- the allocator code
- the dummy output type for inline assembly
- perhaps we could add a
set_alignmentmethod inrustc_codegen_ssathat asks the backend to set the alignment and is called inrustc_codegen_ssain strategic places so that we don't have to worry as much about alignment in the codegens (not sure if this is possible).
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.
It would be important that this refactoring does not result in a performance degradation for rustc_codegen_llvm.
Expected result
A rustc_codegen_gcc that contains less hacks, unsafe code and/or code duplication with rustc_codegen_llvm.
Desirable skills
Knowledge of Rust and basic knowledge of rustc internals, especially the codegen part.
Project size
Small-Medium depending on the chosen scope.
Difficulty
Medium.
Mentor
Zulip streams
Description
The tests/ui/issues directory of the Rust compiler test suite currently contains a large number of miscellaneous tests — approximately 615 in total. These are primarily regression tests that were added after specific issues were fixed. Over time, this directory has become a catch-all, making the test suite harder to navigate and maintain.
Our goal is to keep the UI tests well organised, with each test placed in an appropriate subdirectory based on what it is actually testing. Consolidating such a large number of unrelated tests in a single directory works against this goal.
This project focuses on systematically reviewing these tests and relocating them to more suitable locations within tests/ui.
Here is an approximate plan to tackle this:
- Inspect each test in
tests/ui/issues. - Identify the issue it relates to (the issue number is typically part of the file name).
- Determine a more appropriate subdirectory within
tests/ui, based on the behaviour or feature being tested. - Add explanatory comments where the purpose of the test is not immediately obvious.
- Rename the test file to better reflect what it is testing.
- Add a link to the original issue at the top of the test file.
- Reformat the test where appropriate, taking care with tests that intentionally rely on unusual formatting.
- Re-bless tests where necessary (for example, if a test was previously marked as erroneous), and remove any obsolete
.stderrfiles from the original location.
Expected result
Complete removal of the tests/ui/issues/ directory, with all tests relocated to appropriate subdirectories.
Desirable skills
Familiarity with Rust and compiler tests. Ability to read and understand regression tests. Attention to detail and comfort working with large codebases.
Project size
Small to large. (The size is scalable, depending on how many tests would be ported.)
Difficulty
Medium.
Mentors
Zulip streams
Related links
Description
The Rust compiler and its related infrastructure currently include a number of hiccups and roadblocks for Windows users specifically. This can make it more difficult for new contributors using Windows or one of the Unix-to-NT API translation layers (e.g. Cygwin, MSYS2, etc.), to get started with developing the compiler or even using Rust.
It is easy to stumble into rather weird bugs that are both difficult to debug and fix when compiling and working with Rust on Windows. For example, path normalization being done incorrectly for the host OS is a longtime pain point for Unix translation layers (e.g. MSYS2). Additionally, the "put libs wherever you want" strategy Windows has taken with system libraries makes it difficult to configure the build process correctly, especially where linking to external C libraries.
The standard library also has to work around some pecularities of the Windows API. For example, timing on Windows is based on 100ns increments since Jan 1st 1601, whereas most Unix platforms use milliseconds since Jan 1st 1970. In library code, this difference in API behavior is often not well documented and results in many developer surprises. For example, Checked arithmetic for adding a Duration smaller than 100ns results in a noop.
You can find a number of open issues related to Windows in the Rust issue tracker, by filtering for one of the many Windows target categories, for example O-windows.
Expected result
An overall improvement to the number of issues and hiccups/roadblocks a compiler developer or Rust user is expected to face when using Rust on Windows-based platforms.
Desirable skills
Familiarity with Rust, comfort working with large codebases and, depending on project scope, some of the following (non-exhaustive):
- Familiarity with Windows NT API
- Experience developing on Windows or a translation layer
- A decent amount of experience within your field(s)r of choice
Project size
Small to large. (Size is scalable, depending on the scope of the project.)
Difficulty
Medium to Hard, depending on the issues to be fixed.
Mentor
- Teapot (GitHub, Zulip)
- Teapot is happy to mentor projects fixing most compiler and ecosystem components, or any combination of them as the contributor details in their proposal.
- If you would like to do this project, please reach out so Teapot can tell you if he can mentor the field you would like to work on!
Zulip streams
Description
Rust doesn't currently have a way to restrict the implementability of a trait, nor does Rust have a way to restrict the mutability of a field.
The accepted RFC3323 - Restrictions aims to improve our story around those two points by bringing:
impl(..)restrictions:pub impl(crate) trait Foo {}mut(..)restrictions:pub struct Foo { pub mut(crate) foo: u8 }
Previous attempts at implementing the RFC have stalled.
The goal of this project is to implement both impl and mut restrictions in the Rust compiler, fix any resulting bugs that may be discovered in the course of the project, and add extensive tests for the feature.
Expected result
A working implementation of impl and mut restrictions in the nightly compiler.
Desirable skills
Familiarity with Rust. Attention to detail and comfort working with large codebases.
Project size
Small to medium.
Difficulty
Medium.
Mentors
Zulip streams
Related links
Description
The std::arch module in the standard library provides architecture-specific intrinsic functions, which typically directly map to a single machine instruction.
Currently, it lives in its own repository outside the main Rust compiler repository (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).
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.
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:
- Investigate the CI (continuous integration) test suite of
stdarch, and port as much of it intorustc. This will involve implementing new testing and documentation steps for working withstdarchin the compiler's build system, bootstrap. - Once a sufficient portion of the test suite has been ported,
stdarchshould be changed from a submodule to either a git or Josh subtree, so that compiler contributors are able to make changes tostdarchwhen they modify the compiler. This might involve creating some automation tooling to help with performing regular synchronizations from/tostdarch. See this page for more details.
Expected result
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.
Desirable skills
Intermediate knowledge of Rust. Experience with GitHub Actions or CI workflows is a benefit.
Project size
Small to Medium.
Difficulty
Medium.
Mentor
Zulip streams
Description
Cargo's progress reporting is designed for fairly broad terminal support, only allowing one line of progress output. Small steps have been done to take advantage of more terminal features, like unicode support and hyperlinks, by providing configuration for these with a terminal allow list. Something similar can be done to allow for experimenting with richer progress reporting from Cargo like what buck2 has.
One proposed idea is for Cargo to track operational spans (e.g. Updating, Compiling)
and any non-sticky message within one of those spans is cleared upon span close.
Examples of non-sticky messages include warnings, errors, and a summary line for the command (e.g. Finished).
This would help make Cargo less noisy which would be particularly helpful for
cargo script.
Cargo's internals are tied to the idea of one progress line and will need to be updated to allow for richer progress reporting.
See also
Expected result
- Progress style within Cargo is abstracted away
- Sticky/non-sticky user notifications
- New compilation progress style with configuration
- Initial allow list for terminals to use new style
Desirable skills
Intermediate knowledge of Rust.
Project size
Medium.
Difficulty
Medium.
Mentor
Zulip streams
Description
Cargo maintains Bash and Zsh completions, but they are duplicated and limited in features.
A previous GSoC participant added unstable support for completions in Cargo itself, so we can have a single implementation with per-shell skins (rust-lang/cargo#6645).
There are many more arguments that need custom completers as well as polish in the completion system itself before this can be stabilized.
See
Expected result
Ideal:
- A report to clap maintainers on the state of the unstable completions and why its ready for stabilization
- A report to cargo maintainers on the state of the unstable completions and why its ready for stabilization
Desirable skills
Intermediate knowledge of Rust. Shell familiarity is a bonus.
Project size
Medium.
Difficulty
Medium.
Mentor
Zulip streams
Description
When developers need to extend how Cargo builds their package, they can write a build script. This gives users quite a bit of flexibility but
- Allows running arbitrary code on the users system, requiring extra auditing
- Needs to be compiled and run before the relevant package can be built
- They are all-or-nothing, requiring users to do extra checks to avoid running expensive logic
- They run counter to the principles of third-party build tools that try to mimic Cargo
A developer could make their build script a thin wrapper around a library (e.g. shadow-rs) but a build script still exists to be audited (even if its small) and each individual wrapper build script must be compiled and linked. This is still opaque to third-party build tools.
Leveraging an unstable feature, artifact dependencies, we could allow a developer to say that one or more dependencies should be run as build scripts, passing parameters to them.
This project would add unstable support for build script delegation that can then be evaluated for proposing as an RFC for approval.
See the proposal for more details.
Note: there was a project with a similar topic in GSoC 2025. But since there is a lot of work to be done, we have published this project idea again. The current idea description reflects the current state.
Expected result
Milestones
- An unstable feature for passing parameters to build scripts from
Cargo.toml - An unstable feature for build script delegation, passing parameters to artifact dependencies
Bonus: preparation work to stabilize a subset of artifact dependencies.
Project size
Large.
Mentor
Zulip streams
Description
cargo fmt exists today but only supports formatting Rust code and not also
Cargo.toml.cargo/config.tomlrustfmt.tomlrust-toolchain.tomlclippy.toml
There is a Style Guide entry for Cargo.toml
but it doesn't reflect expectations for how people use Cargo.toml and needs updates.
cargo-cargofmt is a concrete way to explore Style Guide ideas for Cargo.toml to help with the process of updating the style guide and to jump start support for formatting Cargo.toml files in cargo fmt.
Some basic rules are implemented
but there is still more work to be done
for it to serve its purpose.
The goal of this project is to extend cargo-cargofmt with additional formatting rules.
Expected result
cargo-cargofmt contains additional formatting rules
Desirable skills
Intermediate knowledge of Rust.
Project size
Medium.
Difficulty
Easy to medium.
Mentor
Zulip streams
Description
Rustup is an indispensable part of Rust's infrastructure, as it provides easy access to a Rust toolchain to millions of Rust users.
Historically, rustup has been using $RUSTUP_HOME (defaulting to
$HOME/.rustup) and a part of $CARGO_HOME (defaulting to $HOME/.cargo)
environment variable-configurable paths as its config, state, and data
directories, but there has long been a desire to move to a more fine-grained
and standardized solution instead.
It is thus decided by both rustup and cargo teams that, in the future, rustup will default to using XDG paths for its various directories, in collaboration with corresponding cargo support:
On the one hand, its toolchains, .env presets, settings, and cache files
should be placed under the respective XDG paths. An example of this could be
using $XDG_DATA_HOME/rustup/toolchains instead of the current
$RUSTUP_HOME/toolchains.
On the other hand, its binary proxies (a.k.a. shims) should also be placed under a reasonable XDG path to be negotiated with the cargo team, so that it behaves as if it were cargo-installed binary.
The goal of this project is to prepare for the above changes in rustup by:
-
Analyzing the dependents of
$RUSTUP_HOMEand$CARGO_HOMEin rustup (and in cargo when necessary) to logically segment them into finer-grained directories. The defaults will remain unchanged for now, but the relevant code should be refactored to support more flexible directory configuration. -
Establishing a protocol to maintain backward compatibility with existing installations of both rustup and cargo and to properly inform users of the potential changes.
The above should be implemented in a way that aligns with both rustup and cargo's progress towards XDG path support, and thus frequent communication with the cargo team might be necessary in addition to that with rustup.
Expected result
-
rustup should support fine-grained directory configurations rather than the current dual-directory approach, with relevant business logic (esp. that of self-uninstallation) and docs adjusted accordingly.
- This means, if the early adopters would like, they will be able to manually enforce XDG paths on rustup.
-
rustup should be able to no longer enforce
$CARGO_HOMEon cargo to unblock relevant cargo changes towards the same direction.- On the other hand, rustup should try its best to respect
$RUSTUP_HOMEand/or$CARGO_HOMEoverrides and maintain the old behavior if present.
- On the other hand, rustup should try its best to respect
Desirable skills
Intermediate knowledge of Rust.
Project size
Medium.
Difficulty
Medium.
Mentor
Zulip streams
Related Links
- All hands 2025 joint meeting notes on XDG support
- Rustup issue: platform-specific config directories
- Rustup issue: stop nuking
$CARGO_HOMEonself uninstall - Pre-RFC: Split
$CARGO_HOME- Rustup issue: stop setting
$CARGO_HOME
- Rustup issue: stop setting
- XDG paths specification
Description
The libc crate is one of the oldest crates of the Rust ecosystem, long predating Rust 1.0. Additionally, it is one of the most widely used crates in the ecosystem (#4 most downloaded on crates.io).
This combinations means that the current version of the libc crate (v0.2) is very conservative with breaking changes has accumulated a list of things to do in a 1.0 release. Additionally, some of the infrastructure for lib is rather outdated.
Most of the changes required for 1.0 are under the 1.0 milestone. Some of these come from the evolution of the underlying platforms, some come from a desire to use newer language features, while others are simple mistakes that we cannot correct without breaking existing code.
The goal of this project is to prepare and release the next major version of the libc crate.
Note: there was a project with a similar topic in GSoC 2025. But since there is a lot of work to be done, we have published this project idea again. The current idea description reflects the current state.
Expected result
The libc crate is cleaned up and modernized, and released as version 0.3.
Desirable skills
Intermediate knowledge of Rust.
Project size
Medium.
Difficulty
Medium.
Mentor
Zulip streams
Description
cargo-semver-checks is a linter for semantic versioning. It ensures
that Rust crates adhere to semantic versioning by looking for breaking changes in APIs. It's used by many of Rust's
most popular libraries — and even within cargo itself.
cargo-semver-checks can currently catch ~245 different kinds of breaking changes, meaning there are hundreds of kinds of breaking changes it
still cannot catch! Its largest capability gap is the inability to perform type-checking in lints, which is necessary
to detect the breakage between pub fn example(x: i64) {} and pub fn example(x: String) {}, for example.
The goal of this project idea is to design and implement the systems required to support the first batch of type-checking lints.
This specifically lays the ground work for shipping such lints by the hundreds — we're not looking to handle just a few special cases.
cargo-semver-checks has been adding hundreds of new lints per year,
and this will be the project that makes that possible for 2026 and beyond!
This would be a challenging "high risk, high reward" type of project: perfect for candidates looking to put forward
a significant amount of effort, determination, and skill toward a difficult problem with serious real world impact,
of course with support and guidance from a mentor. With luck and (quite a lot of) hard work, the culmination of
the project could even be shipping the first set of type-checking lints in a new cargo-semver-checks release.
Expected result
cargo-semver-checks will be able to catch the breakage in cases like:
- pub fn example(x: i64) {}
+ pub fn example(x: String) {}It will do so by using its declarative query language to notice the API change and capture information regarding it,
then plugging that information into a templating system able to generate a "witness" crate for the API change.
cargo-semver-checks would then automatically run cargo check on the witness crate, which will either pass
without errors (indicating no breakage), or error out indicating a breaking change.
A possible witness for the above example is:
pub fn witness(x: i64) {
crate_being_checked::example(x);
}
which will obviously only compile if the example() function takes an i64, not a String.
While this approach may seem overly complex at first, consider the following change:
- pub fn example(x: i64) {}
+ pub fn example(x: impl Into<i64>) {}This is a case where the type of x changed, but passing i64 still works fine — so this isn't a SemVer-major change.
Therefore, merely noticing that a type has changed is not sufficient to detect breakage, and we must use witness programs instead.
(It is highly impractical to use rustc as a library. It's similarly infeasible to reimplement the type-checker and trait solver ourselves.)
Desirable skills
Intermediate knowledge of Rust, or better. Familiarity with databases, query engines, code generation, or query language design is welcome but not required. Willingness to dive into a complex problem space and find your way around (with guidance, of course) is a must.
Contributors interested in this project idea are strongly encouraged to first familiarize themselves with cargo-semver-checks
and its linting system, which expresses lints as queries over a database-like schema (playground).
The project will require writing lints, extending the schema, writing code-generation code to create witness crates,
considering ways to improve performance in order to ensure a positive user experience, and designing the entire lint-writing process
such that type-checking lints are not challenging nor bespoke, but as normal and easy to write as any other lint.
Project size
Large
Difficulty
High
Mentor
Zulip streams
Related Links
- Playground where you can try querying Rust data
- GitHub issues describing not-yet-implemented lints
- Opportunities to add new schema, enabling new lints
- Query engine adapter
- Study of SemVer breakage in Rust, including more details on "witness" programs
- cargo-semver-checks 2025 year in review, where the "path forward" offers more info about this project idea
- Last year's GSoC project, which built the foundation for type-checking lints that we'd build upon
Description
The Wild linker is a very fast linker written in Rust.
We'd like for it to be possible to use the Wild linker for as large a range of Rust development as possible. Besides porting to other platforms, which is probably too large a scope for a GSoC project, one gap we currently have on Linux is compiling kernel modules. Linux kernel modules can now be written in Rust, but the Wild linker, despite having some linker script support, doesn't support enough linker script features to be able to link a kernel module.
Expected result
Implement more linker-script features. Ideally enough that we can support linking of Linux kernel modules, but even if we can't get that far, getting closer would be awesome. Linker scripts are also used extensively for embedded development, which may be something we could support with Wild in the future.
Desirable skills
Intermediate knowledge of Rust and a willingness to learn more. You don't need to have existing experience with implementing linkers, but it'd be good if upon reading the docs for GNU linker scripts, they at least mostly make sense.
Project size
Medium or large depending on which linker script features are implemented.
Difficulty
Different linker script features are likely to range between easy and hard.
Mentor
Zulip streams
Related links
Description
rust-analyzer has many assists (code actions) that operate on the syntax tree. Most of them are implemented via mutable syntax tree editing, with rowan, our syntax tree library. Unfortunately, the existence of mutable syntax trees prohibits a lot of optimizations in rowan and makes it a lot more memory-heavy and slower. Therefore we'd like to remove our usage of mutable trees.
We developed an API called SyntaxEditor that should be used instead of mutable trees. Currently it is implemented with them under the hood, but it is expected to be easier to get rid of them once all mutation is encapsulated in it.
Expected result
rust-analyzer has no assists or diagnostics quickfixes that use mutable tree editing. This will likely also involve further development of the SyntaxEditor API, as per the needs.
Desirable skills
Knowledge of Rust. Knowledge of the rust-analyzer codebase is an advantage but should not be required.
Project size
Large. However note that the size is scalable; even if the project isn't completed, every assist we migrate is a net benefit.
Difficulty
Easy.
Mentors
Zulip streams
Related Links
- An issue explaining why we should get rid of mutable syntax trees architecture-wise
- Tracking issue for this effort
- A prototype exploring how
rowanwithout mutable trees could look like
Description
While it is not strictly an embedded crate, a lot of the embedded Rust ecosystem uses the serialport crate for serial communication.
We maintain compatibility with the latest long-term support (LTS) release of Yocto for embedded Linux systems of which a new release dropped in 2025. This opens a window of opportunity to include PRs with semver breaking changes and streamline the crate's API for better ergonomics and safety.
At the same time, we can upgrade our Minimum Supported Rust Version (MSRV) (currently 1.59), which has started to cause dependency issues for crate users, as well as inhibiting use of modern features.
Expected results
-
Getting the next major release 5.0 of serialport ready and published.
-
Suggesting and implementing serial API improvements for this release, including those that might require breaking changes.
Desirable skills
Strong familiarity with Rust. Some knowledge of the Rust Embedded ecosystem. At least a basic understanding of serial port operation. Interest in working across multiple (desktop) operating systems. Willingness and ability to do both maintenance and design activities.
We can ship USB serial adapters for testing, if needed.
Project size
Small to medium. The project is scaleable in the sense that there are a lot of smaller individual tasks and progress on every single one helps.
Difficulty
Easy.
Mentors
Matrix channel
Related links