rust.md
May 19, 2026 · View on GitHub
Rust usage:
When integrating Rust code into brave-core, keep the following points in mind:
- Chromium’s networking stack must be used
- The deps being added (and the deps recursively being added) must be approved via an issue posted at brave/reviews
- The new code does not duplicate things already done in Chromium
- https://chromium.googlesource.com/chromium/src/+/main/docs/adding_to_third_party.md#rust also applies generally to all Rust code in brave-core
- Look at existing deps in
third_party/rustand try to match up versions whenever possible. We are trying to avoid having multiple copies of the same third party libs
Updating vendored tool crates
The tools/crates/ directory vendors Rust CLI tools (cargo-audit,
wasm-bindgen-cli, wasm-opt, wasm-pack). To update a single transitive
dependency (e.g. for a security advisory) without re-vendoring everything:
npm run update_brave_tools_crates -- --update-crate=<name>@<version>
This downloads the crate directly from crates.io and patches only the targeted
vendor/ directory and Cargo.lock entry. To do a full re-vendor of all tool
crates, run without arguments:
npm run update_brave_tools_crates
Patching crates
There can be cases where patching crates is necessary. To create a patch file, make changes to a crate and create a patch with:
git format-patch \
--start-number=101 \
--src-prefix=a/brave/ \
--dst-prefix=b/brave/ \
--output-directory \
third_party/rust/chromium_crates_io/patches/some-crate/ \
HEAD^
For general instructions on how this works in upstream Chromium, check these instructions.
Testing an unreleased version of a dependency
gnrt generally only allows you to use published releases from
https://crates.io for dependencies. For dependencies maintained by Brave, it may
be desired to test releases on a local build before publishing an "official"
release.
In this case, you can modify
brave/third_party/rust/chromium_crates_io/Cargo.toml to add a patch section
for your dependency. Then you can use a path or git directive to point to
one of your local checkouts on disk, or a git repository, respectively.
Running gnrt gen will update your source tree to use the correct dependency
versions. Note that the code from the vendored version of your crate will not
be updated (even when running gnrt vendor), you will still need to manually
copy your code changes in.
Updating a patch version
This PR updates
adblock 0.8.0 to adblock 0.8.1 without any brave-core code changes.
Updating a minor version
This PR updates
adblock 0.7 to adblock 0.8. This is generally similar to the patch version
diff, but there are additional related changes (i.e. see
components/brave_shields/adblock/rs/BUILD.gn where a path is changed), along
with additional unrelated changes (brave-core code changes to account for the
newer API).
Review guidelines
A checklist for reviewing Rust code changes, including dependent library crates. This is just a starting point and not a comprehensive list.
- Third-party dependency versions should be aligned with what's already in the upstream chromium or brave trees. If a change needs to update one of those crates, make sure there's at least an issue open for all other users to coordinate migration so we don't ship duplicate code.
- Carefully check any
thread_localuse. Leaf code may be called from different C++ threads in sequence, so thread-local variables won't be consistent. - No IO or system calls are allowed
- Any use of
autocfgin dependencies must be patched out and replaced by config settings inBUILD.gnbased on variables there. Since we don't use cargo, most of these checks won't work, or will produce the wrong values. See here for an example handling these issues.