This is mostly for exercise.
But what path should I take if I wished to suggest/implement a new feature in the language? I wanted to try implementing anonymous enums, just to mess around and learn a bit about rust's internals, but rustc codebase is scary, where should I start? with some specification, rfc?
If you want to implement your feature, https://rustc-dev-guide.rust-lang.org/ is the place to start, it documents the internals of the compiler and how to set up a development environment.
If you want to actually get your feature accepted in the language, the likely place to start is by writing a design proposal ("pre-rfc") and soliciting feedback here on this fine forum. Keep in mind that the vast majority of language feature proposals are rejected. You will want to search for past proposals (searching on this forum and the Rust RFCs repo is a good place to start), and also give detailed motivation of the specific problem your feature would address.
There is a high bar for new language features. Rust already has a backlog of language features to implement. Rust also focuses on backwards compatibility and stability, so there are things it can't change or even improve.
The easier ways to contribute:
Look through tracking issues for accepted features. They're either not fully implemented, or have unresolved questions, or just haven't been used by enough users yet to have confidence they're good. You can help these features move forward.
Contribute to libstd/liballoc. Their code is much easier to understand. The bar for adding new standard library functions is much lower.
Thank you for letting me know
I want to do this mostly for myself and to get a better understanding of compilers. But eventually I'd like to make some contributions that add value to the project
I did some contribution to a lint once. That was quite a nice experience because it’s limited in scope, and it doesn’t feel so severe – worst case that can happen if you introduce some minor bugs is bad lints in corner cases – there’s no (or little) effect on program behavior, performance or correctness; which can mean that even then it’s still an overall improvements. Also, bad lints in corner cases are a very common type of issue. If you want you can search for an existing A-lint or A-diagnostics issue that seems relevant and tractable to you, and then try to find the relevant parts in the compiler source code where you might be able to fix it.
That said, if you just want to try out what it’s like to make a PR to Rust, the standard library, maybe even just the documentation of the standard library, is a good and easy place to start. (I’ve even opened several PRs for typos in the past, for example, which is a nice and trivial case to get used to the procedure.)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.