Want to contribute? Great! First, read this page.

Before you contribute

Before we can use your code, you must sign the Google Individual Contributor License Agreement (CLA), which you can do online.

The CLA is necessary mainly because you own the copyright to your changes, even after your contribution becomes part of our codebase, so we need your permission to use and distribute your code. We also need to be sure of various other things — for instance that you‘ll tell us if you know that your code infringes on other people’s patents. You don‘t have to sign the CLA until after you’ve submitted your code for review and a member has approved it, but you must do it before we can put your code into our codebase.

Before you start working on a larger contribution, you should get in touch with us first. Use the issue tracker to explain your idea so we can help and possibly guide you.

Contributions made by corporations are covered by a different agreement than the one above, the Software Grant and Corporate Contributor License Agreement.

Code Reviews and Contributing PRs

All submissions, including submissions by project members, require review.

AI Generated Contributions

To ensure maintainability & sustainability of rules_rust in the LLM era, we’re adopting LLVM’s AI tools policy. As a short summary, when contributing to rules_rust you are expected to:

  • Understand and Own the Code: You may use AI tools, but you are fully accountable for the work. You must thoroughly read, understand, and self-review all content before submitting it for review.
  • Learn from Feedback: When maintainers review your work, use their feedback as a human learning opportunity to grow your skills, rather than simply funneling their comments back into an LLM to generate a quick fix.
  • Be Transparent: Clearly label any contribution that contains a substantial amount of AI-generated content (e.g., using an Assisted-by commit trailer).

Public Interface changes

If your proposed change affects an existing or adds a public API (e.g new attribute, new build setting), please file an issue explaining the problem space & proposed design first.

As Rust & Bazel are seeing increased adoption in the industry, we see more and more PRs that add/enhance the public facing interface of rules_rust (e.g new attributes, new rules, new build settings). Sometimes such PRs are near-universally beneficial, other times they address specific/narrow use cases. In its present shape, the core ruleset does not provide a sufficient level of configurability so that the latter use cases can be addressed locally. We will soon start a redesign of the core ruleset that aims to allow for sufficient configurability so that users can address their own needs without expanding the rules_rust API surface.

Adding New Rules

We do not accept new non-core rules to the rules_rust repository.

In its current state, rules_rust contains functionality broader than most rulesets: in addition to a core ruleset, it also contains functionality for automated BUILD/bzl file generation for crates, IDE integration via rust-analyzer, docs generation via rustdoc, C++ interop via bindgen, Js/Ts interop via wasm_bindgen etc. At present time there are areas that the maintainers don’t have sufficient expertise in, or where there is a single maintainer that can meaningfully act on incoming PRs and issues, making it difficult for interested parties to contribute. To address this, we will be splitting the non-core rulesets into separate repositories. This will allow for additional maintainers to join specific areas. For areas where we don’t find maintainers, we’ll deprecate and retire.

Core Rules

Rules used to compile Rust code.

  • rust_library
  • rust_binary
  • rust_test
  • rust_static_library
  • rust_shared_library
  • rust_proc_macro
  • cargo_build_script

Unowned / Undermaintained / Undertested areas

There are areas of rules_rust that no maintainers currently have expertise in. For these areas, expect some friction during contribution:

  • prost Best effort maintenance, long term these rules will not live in rules_rust. If you’re interested in taking over maintenance please reach out.
  • wasm-bindgen Best effort maintenance, long term these rules will not live in rules_rust. If you’re interested in taking over maintenance please reach out.
  • Windows as host Best effort maintenance, with no capability / bandwidth to help contributors. Experts willing to help review PRs would be much appreciated!
  • Platforms other than Linux / MacOS / Windows Best effort maintenance, no CI testing.

Testing

A PR should contain tests for the change where feasible.

Stale PRs and Issues

PRs and issues that are in awaiting-response state for more than 90 days will be closed as inactive.