Rules Rust

This repository provides rules for building Rust projects with Bazel.

Setup

The rules are released, and releases can be found on the GitHub Releases page. We recommend using the latest release from that page.

Bzlmod

Note that rules_rust bzlmod support is still a work in progress. Most features should work, but bugs are more likely. This is not a desired end-state - please report (or better yet, help fix!) bugs you run into.

To use rules_rust in a project using bzlmod, add the following to your MODULE.bazel file:

bazel_dep(name = "rules_rust", version = "0.48.0")

Don't forget to substitute in your desired release's version number.

WORKSPACE

To use rules_rust in a project using a WORKSPACE file, add the following to your WORKSPACE file to add the external repositories for the Rust toolchain:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

# To find additional information on this release or newer ones visit:
# https://github.com/bazelbuild/rules_rust/releases
http_archive(
    name = "rules_rust",
    integrity = "sha256-Weev1uz2QztBlDA88JX6A1N72SucD1V8lBsaliM0TTg=",
    urls = ["https://github.com/bazelbuild/rules_rust/releases/download/0.48.0/rules_rust-v0.48.0.tar.gz"],
)

load("@rules_rust//rust:repositories.bzl", "rules_rust_dependencies", "rust_register_toolchains")

rules_rust_dependencies()

rust_register_toolchains()

Don't forget to substitute in your desired release's version number and integrity hash.

Specifying Rust version

To build with a particular version of the Rust compiler, pass that version to rust_register_toolchains:

rust_register_toolchains(
    edition = "2021",
    versions = [
        "1.79.0"
    ],
)

As well as an exact version, versions can accept nightly/{iso_date} and beta/{iso_date} strings for toolchains from different release channels.

rust_register_toolchains(
    edition = "2021",
    versions = [
        "nightly/2024-06-13",
    ],
)

By default, a stable and nightly toolchain will be registered if no versions are passed to rust_register_toolchains. However, if only 1 version is passed and it is from the nightly or beta release channels (i.e. not stable), then a build setting must also be set in the project's .bazelrc file.

build --@rules_rust//rust/toolchain/channel=nightly

Failure to do so will result in rules attempting to match a stable toolchain when one was not registered.

Supported bazel versions

The oldest version of Bazel the main branch is tested against is 7.3.1. Previous versions may still be functional in certain environments, but this is the minimum version we strive to fully support.

We test these rules against the latest rolling releases of Bazel, and aim for compatibility with them, but prioritise stable releases over rolling releases where necessary.

Supported platforms

We aim to support Linux and macOS.

We do not have sufficient maintainer expertise to support Windows. Most things probably work, but we have had to disable many tests in CI because we lack the expertise to fix them. We welcome contributions to help improve its support.

Windows support for some features requires --enable_runfiles to be passed to Bazel, we recommend putting it in your bazelrc. See Using Bazel on Windows for more Windows-specific recommendations.

Rules

• defs: standard rust rules for building and testing libraries and binaries.
• rustdoc: rules for generating and testing rust documentation.
• clippy: rules for running clippy.
• rustfmt: rules for running rustfmt.
• cargo: Rules dedicated to Cargo compatibility. ie: build.rs scripts.
• crate_universe: Rules for generating Bazel targets for external crate dependencies.

Experimental rules

• rust_analyzer: rules for generating rust-project.json files for rust-analyzer

3rd party rules

• rust_bindgen: rules for generating C++ bindings.
• rust_prost: rules for generating protobuf and gRPC stubs using prost.
• rust_protobuf: rules for generating protobuf and gRPC stubs with rust-protobuf
• rust_wasm_bindgen: rules for generating WebAssembly bindings.

Full API

You can also browse the full API in one page.

Public entry point to all Rust rules and supported APIs.

Rules

• rust_binary
• rust_library
• rust_library_group
• rust_proc_macro
• rust_shared_library
• rust_static_library
• rust_test

Functions

• rust_test_suite

rust_binary

load("@rules_rust//rust:defs.bzl", "rust_binary")

rust_binary(name, deps, srcs, data, aliases, alwayslink, binary_name, compile_data, crate_features,
            crate_name, crate_root, crate_type, edition, env, experimental_use_cc_common_link,
            linker_script, malloc, out_binary, platform, proc_macro_deps, rustc_env, rustc_env_files,
            rustc_flags, stamp, version)

Builds a Rust binary crate.

Example:

Suppose you have the following directory structure for a Rust project with a library crate, hello_lib, and a binary crate, hello_world that uses the hello_lib library:

[workspace]/
    WORKSPACE
    hello_lib/
        BUILD
        src/
            lib.rs
    hello_world/
        BUILD
        src/
            main.rs

hello_lib/src/lib.rs:

#![allow(unused)]
fn main() {
pub struct Greeter {
    greeting: String,
}

impl Greeter {
    pub fn new(greeting: &str) -> Greeter {
        Greeter { greeting: greeting.to_string(), }
    }

    pub fn greet(&self, thing: &str) {
        println!("{} {}", &self.greeting, thing);
    }
}
}

hello_lib/BUILD:

package(default_visibility = ["//visibility:public"])

load("@rules_rust//rust:defs.bzl", "rust_library")

rust_library(
    name = "hello_lib",
    srcs = ["src/lib.rs"],
)

hello_world/src/main.rs:

extern crate hello_lib;

fn main() {
    let hello = hello_lib::Greeter::new("Hello");
    hello.greet("world");
}

hello_world/BUILD:

load("@rules_rust//rust:defs.bzl", "rust_binary")

rust_binary(
    name = "hello_world",
    srcs = ["src/main.rs"],
    deps = ["//hello_lib"],
)

Build and run hello_world:

$ bazel run //hello_world
INFO: Found 1 target...
Target //examples/rust/hello_world:hello_world up-to-date:
bazel-bin/examples/rust/hello_world/hello_world
INFO: Elapsed time: 1.308s, Critical Path: 1.22s

INFO: Running command line: bazel-bin/examples/rust/hello_world/hello_world
Hello world

On Windows, a PDB file containing debugging information is available under the key pdb_file in OutputGroupInfo. Similarly on macOS, a dSYM folder is available under the key dsym_folder in OutputGroupInfo.

ATTRIBUTES

rust_library

load("@rules_rust//rust:defs.bzl", "rust_library")

rust_library(name, deps, srcs, data, aliases, alwayslink, compile_data, crate_features, crate_name,
             crate_root, disable_pipelining, edition, proc_macro_deps, rustc_env, rustc_env_files,
             rustc_flags, stamp, version)

Builds a Rust library crate.

Example:

Suppose you have the following directory structure for a simple Rust library crate:

[workspace]/
    WORKSPACE
    hello_lib/
        BUILD
        src/
            greeter.rs
            lib.rs

hello_lib/src/greeter.rs:

#![allow(unused)]
fn main() {
pub struct Greeter {
    greeting: String,
}

impl Greeter {
    pub fn new(greeting: &str) -> Greeter {
        Greeter { greeting: greeting.to_string(), }
    }

    pub fn greet(&self, thing: &str) {
        println!("{} {}", &self.greeting, thing);
    }
}
}

hello_lib/src/lib.rs:

#![allow(unused)]
fn main() {
pub mod greeter;
}

hello_lib/BUILD:

package(default_visibility = ["//visibility:public"])

load("@rules_rust//rust:defs.bzl", "rust_library")

rust_library(
    name = "hello_lib",
    srcs = [
        "src/greeter.rs",
        "src/lib.rs",
    ],
)

Build the library:

$ bazel build //hello_lib
INFO: Found 1 target...
Target //examples/rust/hello_lib:hello_lib up-to-date:
bazel-bin/examples/rust/hello_lib/libhello_lib.rlib
INFO: Elapsed time: 1.245s, Critical Path: 1.01s

ATTRIBUTES

rust_library_group

load("@rules_rust//rust:defs.bzl", "rust_library_group")

rust_library_group(name, deps)

Functions as an alias for a set of dependencies.

Specifically, the following are equivalent:

rust_library_group(
    name = "crate_group",
    deps = [
        ":crate1",
        ":crate2",
    ],
)

rust_library(
    name = "foobar",
    deps = [":crate_group"],
    ...
)

and

rust_library(
    name = "foobar",
    deps = [
        ":crate1",
        ":crate2",
    ],
    ...
)

ATTRIBUTES

rust_proc_macro

load("@rules_rust//rust:defs.bzl", "rust_proc_macro")

rust_proc_macro(name, deps, srcs, data, aliases, alwayslink, compile_data, crate_features,
                crate_name, crate_root, edition, proc_macro_deps, rustc_env, rustc_env_files,
                rustc_flags, stamp, version)

Builds a Rust proc-macro crate.

ATTRIBUTES

rust_shared_library

load("@rules_rust//rust:defs.bzl", "rust_shared_library")

rust_shared_library(name, deps, srcs, data, aliases, alwayslink, compile_data, crate_features,
                    crate_name, crate_root, edition, experimental_use_cc_common_link, malloc,
                    platform, proc_macro_deps, rustc_env, rustc_env_files, rustc_flags, stamp,
                    version)

Builds a Rust shared library.

This shared library will contain all transitively reachable crates and native objects. It is meant to be used when producing an artifact that is then consumed by some other build system (for example to produce a shared library that Python program links against).

This rule provides CcInfo, so it can be used everywhere Bazel expects rules_cc.

When building the whole binary in Bazel, use rust_library instead.

ATTRIBUTES

rust_static_library

load("@rules_rust//rust:defs.bzl", "rust_static_library")

rust_static_library(name, deps, srcs, data, aliases, alwayslink, compile_data, crate_features,
                    crate_name, crate_root, edition, platform, proc_macro_deps, rustc_env,
                    rustc_env_files, rustc_flags, stamp, version)

Builds a Rust static library.

This static library will contain all transitively reachable crates and native objects. It is meant to be used when producing an artifact that is then consumed by some other build system (for example to produce an archive that Python program links against).

This rule provides CcInfo, so it can be used everywhere Bazel expects rules_cc.

When building the whole binary in Bazel, use rust_library instead.

ATTRIBUTES

rust_test

load("@rules_rust//rust:defs.bzl", "rust_test")

rust_test(name, deps, srcs, data, aliases, alwayslink, compile_data, crate, crate_features,
          crate_name, crate_root, edition, env, env_inherit, experimental_use_cc_common_link, malloc,
          platform, proc_macro_deps, rustc_env, rustc_env_files, rustc_flags, stamp,
          use_libtest_harness, version)

Builds a Rust test crate.

Examples:

Suppose you have the following directory structure for a Rust library crate with unit test code in the library sources:

[workspace]/
    WORKSPACE
    hello_lib/
        BUILD
        src/
            lib.rs

hello_lib/src/lib.rs:

#![allow(unused)]
fn main() {
pub struct Greeter {
    greeting: String,
}

impl Greeter {
    pub fn new(greeting: &str) -> Greeter {
        Greeter { greeting: greeting.to_string(), }
    }

    pub fn greet(&self, thing: &str) -> String {
        format!("{} {}", &self.greeting, thing)
    }
}

#[cfg(test)]
mod test {
    use super::Greeter;

    #[test]
    fn test_greeting() {
        let hello = Greeter::new("Hi");
        assert_eq!("Hi Rust", hello.greet("Rust"));
    }
}
}

To build and run the tests, simply add a rust_test rule with no srcs and only depends on the hello_lib rust_library target via the crate attribute:

hello_lib/BUILD:

load("@rules_rust//rust:defs.bzl", "rust_library", "rust_test")

rust_library(
    name = "hello_lib",
    srcs = ["src/lib.rs"],
)

rust_test(
    name = "hello_lib_test",
    crate = ":hello_lib",
    # You may add other deps that are specific to the test configuration
    deps = ["//some/dev/dep"],
)

Run the test with bazel test //hello_lib:hello_lib_test.

Example: test directory

Integration tests that live in the tests directory, they are essentially built as separate crates. Suppose you have the following directory structure where greeting.rs is an integration test for the hello_lib library crate:

[workspace]/
    WORKSPACE
    hello_lib/
        BUILD
        src/
            lib.rs
        tests/
            greeting.rs

hello_lib/tests/greeting.rs:

#![allow(unused)]
fn main() {
extern crate hello_lib;

use hello_lib;

#[test]
fn test_greeting() {
    let hello = greeter::Greeter::new("Hello");
    assert_eq!("Hello world", hello.greeting("world"));
}
}

To build the greeting.rs integration test, simply add a rust_test target with greeting.rs in srcs and a dependency on the hello_lib target:

hello_lib/BUILD:

load("@rules_rust//rust:defs.bzl", "rust_library", "rust_test")

rust_library(
    name = "hello_lib",
    srcs = ["src/lib.rs"],
)

rust_test(
    name = "greeting_test",
    srcs = ["tests/greeting.rs"],
    deps = [":hello_lib"],
)

Run the test with bazel test //hello_lib:greeting_test.

ATTRIBUTES

rust_test_suite

load("@rules_rust//rust:defs.bzl", "rust_test_suite")

rust_test_suite(name, srcs, shared_srcs, kwargs)

A rule for creating a test suite for a set of rust_test targets.

This rule can be used for setting up typical rust integration tests. Given the following directory structure:

[crate]/
    BUILD.bazel
    src/
        lib.rs
        main.rs
    tests/
        integrated_test_a.rs
        integrated_test_b.rs
        integrated_test_c.rs
        patterns/
            fibonacci_test.rs
        helpers/
            mod.rs

The rule can be used to generate rust_test targets for each source file under tests and a test_suite which encapsulates all tests.

load("//rust:defs.bzl", "rust_binary", "rust_library", "rust_test_suite")

rust_library(
    name = "math_lib",
    srcs = ["src/lib.rs"],
)

rust_binary(
    name = "math_bin",
    srcs = ["src/main.rs"],
)

rust_test_suite(
    name = "integrated_tests_suite",
    srcs = glob(["tests/**"]),
    shared_srcs=glob(["tests/helpers/**"]),
    deps = [":math_lib"],
)

PARAMETERS

Overview

Clippy is a tool for catching common mistakes in Rust code and improving it. An expansive list of lints and the justification can be found in their documentation.

Setup

Simply add the following to the .bazelrc file in the root of your workspace:

build --aspects=@rules_rust//rust:defs.bzl%rust_clippy_aspect
build --output_groups=+clippy_checks

This will enable clippy on all Rust targets.

Note that targets tagged with no-clippy will not perform clippy checks

To use a local clippy.toml, add the following flag to your .bazelrc. Note that due to the upstream implementation of clippy, this file must be named either .clippy.toml or clippy.toml. Using a custom config file requires Rust 1.34.0 or newer.

build --@rules_rust//rust/settings:clippy.toml=//:clippy.toml

Rules

• rust_clippy

Aspects

• rust_clippy_aspect

rust_clippy

load("@rules_rust//rust:defs.bzl", "rust_clippy")

rust_clippy(name, deps)

Executes the clippy checker on a specific target.

Similar to rust_clippy_aspect, but allows specifying a list of dependencies within the build system.

For example, given the following example targets:

load("@rules_rust//rust:defs.bzl", "rust_library", "rust_test")

rust_library(
    name = "hello_lib",
    srcs = ["src/lib.rs"],
)

rust_test(
    name = "greeting_test",
    srcs = ["tests/greeting.rs"],
    deps = [":hello_lib"],
)

Rust clippy can be set as a build target with the following:

load("@rules_rust//rust:defs.bzl", "rust_clippy")

rust_clippy(
    name = "hello_library_clippy",
    testonly = True,
    deps = [
        ":hello_lib",
        ":greeting_test",
    ],
)

ATTRIBUTES

rust_clippy_aspect

load("@rules_rust//rust:defs.bzl", "rust_clippy_aspect")

rust_clippy_aspect(name)

Executes the clippy checker on specified targets.

This aspect applies to existing rust_library, rust_test, and rust_binary rules.

As an example, if the following is defined in examples/hello_lib/BUILD.bazel:

load("@rules_rust//rust:defs.bzl", "rust_library", "rust_test")

rust_library(
    name = "hello_lib",
    srcs = ["src/lib.rs"],
)

rust_test(
    name = "greeting_test",
    srcs = ["tests/greeting.rs"],
    deps = [":hello_lib"],
)

Then the targets can be analyzed with clippy using the following command:

$ bazel build --aspects=@rules_rust//rust:defs.bzl%rust_clippy_aspect               --output_groups=clippy_checks //hello_lib:all

ASPECT ATTRIBUTES

ATTRIBUTES

Overview

Rustfmt is a tool for formatting Rust code according to style guidelines. By default, Rustfmt uses a style which conforms to the Rust style guide that has been formalized through the style RFC process. A complete list of all configuration options can be found in the Rustfmt GitHub Pages.

Setup

Formatting your Rust targets' source code requires no setup outside of loading rules_rust in your workspace. Simply run bazel run @rules_rust//:rustfmt to format source code.

In addition to this formatter, a simple check can be performed using the rustfmt_aspect aspect by running

bazel build --aspects=@rules_rust//rust:defs.bzl%rustfmt_aspect --output_groups=rustfmt_checks

Add the following to a .bazelrc file to enable this check during the build phase.

build --aspects=@rules_rust//rust:defs.bzl%rustfmt_aspect
build --output_groups=+rustfmt_checks

It's recommended to only enable this aspect in your CI environment so formatting issues do not impact user's ability to rapidly iterate on changes.

The rustfmt_aspect also uses a --@rules_rust//rust/settings:rustfmt.toml setting which determines the configuration file used by the formatter (@rules_rust//tools/rustfmt) and the aspect (rustfmt_aspect). This flag can be added to your .bazelrc file to ensure a consistent config file is used whenever rustfmt is run:

build --@rules_rust//rust/settings:rustfmt.toml=//:rustfmt.toml

Tips

Any target which uses Bazel generated sources will cause the @rules_rust//tools/rustfmt tool to fail with failed to resolve mod `MOD` . To avoid failures, skip_children = true is recommended to be set in the workspace's rustfmt.toml file which allows rustfmt to run on these targets without failing.

Rules

• rustfmt_test

Aspects

• rustfmt_aspect

rustfmt_test

load("@rules_rust//rust:defs.bzl", "rustfmt_test")

rustfmt_test(name, targets)

A test rule for performing rustfmt --check on a set of targets

ATTRIBUTES

rustfmt_aspect

load("@rules_rust//rust:defs.bzl", "rustfmt_aspect")

rustfmt_aspect(name)

This aspect is used to gather information about a crate for use in rustfmt and perform rustfmt checks

Output Groups:

• rustfmt_checks: Executes rustfmt --check on the specified target.

The build setting @rules_rust//rust/settings:rustfmt.toml is used to control the Rustfmt configuration settings used at runtime.

This aspect is executed on any target which provides the CrateInfo provider. However users may tag a target with no-rustfmt or no-format to have it skipped. Additionally, generated source files are also ignored by this aspect.

ASPECT ATTRIBUTES

ATTRIBUTES

Public entry point to all Rust rules and supported APIs.

Rules

• rust_doc
• rust_doc_test

rust_doc

load("@rules_rust//rust:defs.bzl", "rust_doc")

rust_doc(name, crate, html_after_content, html_before_content, html_in_header, markdown_css,
         rustc_flags, rustdoc_flags)

Generates code documentation.

Example: Suppose you have the following directory structure for a Rust library crate:

[workspace]/
    WORKSPACE
    hello_lib/
        BUILD
        src/
            lib.rs

To build rustdoc documentation for the hello_lib crate, define a rust_doc rule that depends on the the hello_lib rust_library target:

package(default_visibility = ["//visibility:public"])

load("@rules_rust//rust:defs.bzl", "rust_library", "rust_doc")

rust_library(
    name = "hello_lib",
    srcs = ["src/lib.rs"],
)

rust_doc(
    name = "hello_lib_doc",
    crate = ":hello_lib",
)

Running bazel build //hello_lib:hello_lib_doc will build a zip file containing the documentation for the hello_lib library crate generated by rustdoc.

ATTRIBUTES

rust_doc_test

load("@rules_rust//rust:defs.bzl", "rust_doc_test")

rust_doc_test(name, deps, crate, proc_macro_deps)

Runs Rust documentation tests.

Example:

Suppose you have the following directory structure for a Rust library crate:

[workspace]/
WORKSPACE
hello_lib/
    BUILD
    src/
        lib.rs

To run documentation tests for the hello_lib crate, define a rust_doc_test target that depends on the hello_lib rust_library target:

package(default_visibility = ["//visibility:public"])

load("@rules_rust//rust:defs.bzl", "rust_library", "rust_doc_test")

rust_library(
    name = "hello_lib",
    srcs = ["src/lib.rs"],
)

rust_doc_test(
    name = "hello_lib_doc_test",
    crate = ":hello_lib",
)

Running bazel test //hello_lib:hello_lib_doc_test will run all documentation tests for the hello_lib library crate.

ATTRIBUTES

Cargo

Common definitions for the @rules_rust//cargo package

Rules

• cargo_dep_env

Functions

• cargo_build_script
• cargo_env

Repository Rules

• cargo_bootstrap_repository

cargo_dep_env

load("@rules_rust//cargo:defs.bzl", "cargo_dep_env")

cargo_dep_env(name, src, out_dir)

A rule for generating variables for dependent cargo_build_scripts without a build script. This is useful for using Bazel rules instead of a build script, while also generating configuration information for build scripts which depend on this crate.

ATTRIBUTES

cargo_build_script

load("@rules_rust//cargo:defs.bzl", "cargo_build_script")

cargo_build_script(name, edition, crate_name, crate_root, srcs, crate_features, version, deps,
                   link_deps, proc_macro_deps, build_script_env, use_default_shell_env, data,
                   compile_data, tools, links, rundir, rustc_env, rustc_env_files, rustc_flags,
                   visibility, tags, aliases, pkg_name, kwargs)

Compile and execute a rust build script to generate build attributes

This rules take the same arguments as rust_binary.

Example:

Suppose you have a crate with a cargo build script build.rs:

[workspace]/
    hello_lib/
        BUILD
        build.rs
        src/
            lib.rs

Then you want to use the build script in the following:

hello_lib/BUILD:

package(default_visibility = ["//visibility:public"])

load("@rules_rust//rust:defs.bzl", "rust_binary", "rust_library")
load("@rules_rust//cargo:defs.bzl", "cargo_build_script")

# This will run the build script from the root of the workspace, and
# collect the outputs.
cargo_build_script(
    name = "build_script",
    srcs = ["build.rs"],
    # Optional environment variables passed during build.rs compilation
    rustc_env = {
       "CARGO_PKG_VERSION": "0.1.2",
    },
    # Optional environment variables passed during build.rs execution.
    # Note that as the build script's working directory is not execroot,
    # execpath/location will return an absolute path, instead of a relative
    # one.
    build_script_env = {
        "SOME_TOOL_OR_FILE": "$(execpath @tool//:binary)"
    },
    # Optional data/tool dependencies
    data = ["@tool//:binary"],
)

rust_library(
    name = "hello_lib",
    srcs = [
        "src/lib.rs",
    ],
    deps = [":build_script"],
)

The hello_lib target will be build with the flags and the environment variables declared by the build script in addition to the file generated by it.

PARAMETERS

cargo_env

load("@rules_rust//cargo:defs.bzl", "cargo_env")

cargo_env(env)

A helper for generating platform specific environment variables

load("@rules_rust//rust:defs.bzl", "rust_common")
load("@rules_rust//cargo:defs.bzl", "cargo_bootstrap_repository", "cargo_env")

cargo_bootstrap_repository(
    name = "bootstrapped_bin",
    cargo_lockfile = "//:Cargo.lock",
    cargo_toml = "//:Cargo.toml",
    srcs = ["//:resolver_srcs"],
    version = rust_common.default_version,
    binary = "my-crate-binary",
    env = {
        "x86_64-unknown-linux-gnu": cargo_env({
            "FOO": "BAR",
        }),
    },
    env_label = {
        "aarch64-unknown-linux-musl": cargo_env({
            "DOC": "//:README.md",
        }),
    }
)

PARAMETERS

RETURNS

str: A json encoded string of the environment variables

cargo_bootstrap_repository

load("@rules_rust//cargo:defs.bzl", "cargo_bootstrap_repository")

cargo_bootstrap_repository(name, srcs, binary, build_mode, cargo_config, cargo_lockfile, cargo_toml,
                           compressed_windows_toolchain_names, env, env_label, repo_mapping,
                           rust_toolchain_cargo_template, rust_toolchain_rustc_template, timeout,
                           version)

A rule for bootstrapping a Rust binary using Cargo

ATTRIBUTES

Overview

For non-Cargo projects, rust-analyzer depends on a rust-project.json file at the root of the project that describes its structure. The rust_analyzer rule facilitates generating such a file.

Setup

First, ensure rules_rust is setup in your workspace. By default, rust_register_toolchains will ensure a rust_analyzer_toolchain is registered within the WORKSPACE.

Next, load the dependencies for the rust-project.json generator tool:

load("@rules_rust//tools/rust_analyzer:deps.bzl", "rust_analyzer_dependencies")

rust_analyzer_dependencies()

Finally, run bazel run @rules_rust//tools/rust_analyzer:gen_rust_project whenever dependencies change to regenerate the rust-project.json file. It should be added to .gitignore because it is effectively a build artifact. Once the rust-project.json has been generated in the project root, rust-analyzer can pick it up upon restart.

For users who do not use rust_register_toolchains to register toolchains, the following can be added to their WORKSPACE to register a rust_analyzer_toolchain. Please make sure the Rust version used in this toolchain matches the version used by the currently registered toolchain or the sources/documentation will not match what's being compiled with and can lead to confusing results.

load("@rules_rust//rust:repositories.bzl", "rust_analyzer_toolchain_repository")

register_toolchains(rust_analyzer_toolchain_repository(
    name = "rust_analyzer_toolchain",
    # This should match the currently registered toolchain.
    version = "1.63.0",
))

VSCode

To set this up using VSCode, users should first install the rust_analyzer plugin. With that in place, the following task can be added to the .vscode/tasks.json file of the workspace to ensure a rust-project.json file is created and up to date when the editor is opened.

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Generate rust-project.json",
            "command": "bazel",
            "args": [
                "run",
                "//tools/rust_analyzer:gen_rust_project"
            ],
            "options": {
                "cwd": "${workspaceFolder}"
            },
            "group": "build",
            "problemMatcher": [],
            "presentation": {
                "reveal": "never",
                "panel": "dedicated",
            },
            "runOptions": {
                "runOn": "folderOpen"
            }
        },
    ]
}

Alternative vscode option (prototype)

Add the following to your bazelrc:

build --@rules_rust//rust/settings:rustc_output_diagnostics=true --output_groups=+rust_lib_rustc_output,+rust_metadata_rustc_output

Then you can use a prototype rust-analyzer plugin that automatically collects the outputs whenever you recompile.

Aspects

• rust_analyzer_aspect

rust_analyzer_aspect

load("@rules_rust//rust:defs.bzl", "rust_analyzer_aspect")

rust_analyzer_aspect(name)

Annotates rust rules with RustAnalyzerInfo later used to build a rust-project.json

ASPECT ATTRIBUTES

ATTRIBUTES

Settings

Flags which control granular behavior of various Rust rules.

Rust settings

Definitions for all @rules_rust//rust settings

capture_clippy_output

--@rules_rust//rust/settings:capture_clippy_output

Control whether to print clippy output or store it to a file, using the configured error_format.

clippy_flag

--@rules_rust//rust/settings:clippy_flag

Add a custom clippy flag from the command line with --@rules_rust//rust/settings:clippy_flag.

Multiple uses are accumulated and appended after the extra_rustc_flags.

clippy_flags

--@rules_rust//rust/settings:clippy_flags

This setting may be used to pass extra options to clippy from the command line.

It applies across all targets.

clippy_toml

--@rules_rust//rust/settings:clippy_toml

This setting is used by the clippy rules. See https://bazelbuild.github.io/rules_rust/rust_clippy.html

Note that this setting is actually called clippy.toml.

codegen_units

--@rules_rust//rust/settings:codegen_units

The default value for --codegen-units which also affects resource allocation for rustc actions.

Note that any value 0 or less will prevent this flag from being passed by Bazel and allow rustc to perform it's default behavior.

https://doc.rust-lang.org/rustc/codegen-options/index.html#codegen-units

error_format

--@rules_rust//rust/settings:error_format

This setting may be changed from the command line to generate machine readable errors.

experimental_link_std_dylib

--@rules_rust//rust/settings:experimental_link_std_dylib

A flag to control whether to link libstd dynamically.

experimental_per_crate_rustc_flag

--@rules_rust//rust/settings:experimental_per_crate_rustc_flag

Add additional rustc_flag to matching crates from the command line with --@rules_rust//rust/settings:experimental_per_crate_rustc_flag.

The expected flag format is prefix_filter@flag, where any crate with a label or execution path starting with the prefix filter will be built with the given flag. The label matching uses the canonical form of the label (i.e //package:label_name). The execution path is the relative path to your workspace directory including the base name (including extension) of the crate root. This flag is only applied to the exec configuration (proc-macros, cargo_build_script, etc). Multiple uses are accumulated.

experimental_use_cc_common_link

--@rules_rust//rust/settings:experimental_use_cc_common_link

A flag to control whether to link rust_binary and rust_test targets using cc_common.link instead of rustc.

experimental_use_coverage_metadata_files

--@rules_rust//rust/settings:experimental_use_coverage_metadata_files

A flag to have coverage tooling added as coverage_common.instrumented_files_info.metadata_files instead of reporting tools like llvm-cov and llvm-profdata as runfiles to each test.

experimental_use_global_allocator

--@rules_rust//rust/settings:experimental_use_global_allocator

A flag to indicate that a global allocator is in use when using --@rules_rust//rust/settings:experimental_use_cc_common_link

Users need to specify this flag because rustc generates different set of symbols at link time when a global allocator is in use. When the linking is not done by rustc, the rust_toolchain itself provides the appropriate set of symbols.

experimental_use_sh_toolchain_for_bootstrap_process_wrapper

--@rules_rust//rust/settings:experimental_use_sh_toolchain_for_bootstrap_process_wrapper

A flag to control whether the shell path from a shell toolchain (@bazel_tools//tools/sh:toolchain_type) is embedded into the bootstrap process wrapper for the .sh file.

extra_exec_rustc_flag

--@rules_rust//rust/settings:extra_exec_rustc_flag

Add additional rustc_flags in the exec configuration from the command line with --@rules_rust//rust/settings:extra_exec_rustc_flag.

Multiple uses are accumulated and appended after the extra_exec_rustc_flags.

extra_exec_rustc_flags

--@rules_rust//rust/settings:extra_exec_rustc_flags

This setting may be used to pass extra options to rustc from the command line in exec configuration.

It applies across all targets whereas the rustc_flags option on targets applies only to that target. This can be useful for passing build-wide options such as LTO.

extra_rustc_flag

--@rules_rust//rust/settings:extra_rustc_flag

Add additional rustc_flag from the command line with --@rules_rust//rust/settings:extra_rustc_flag.

Multiple uses are accumulated and appended after the extra_rustc_flags.

extra_rustc_flags

--@rules_rust//rust/settings:extra_rustc_flags

This setting may be used to pass extra options to rustc from the command line in non-exec configuration.

It applies across all targets whereas the rustc_flags option on targets applies only to that target. This can be useful for passing build-wide options such as LTO.

incompatible_change_rust_test_compilation_output_directory

--@rules_rust//rust/settings:incompatible_change_rust_test_compilation_output_directory

A flag to put rust_test compilation outputs in the same directory as the rust_library compilation outputs.

incompatible_do_not_include_data_in_compile_data

--@rules_rust//rust/settings:incompatible_do_not_include_data_in_compile_data

A flag to control whether to include data files in compile_data.

lto

--@rules_rust//rust/settings:lto

A build setting which specifies the link time optimization mode used when building Rust code.

no_std

--@rules_rust//rust/settings:no_std

This setting may be used to enable builds without the standard library.

Currently only no_std + alloc is supported, which can be enabled with setting the value to "alloc". In the future we could add support for additional modes, e.g "core", "alloc,collections".

pipelined_compilation

--@rules_rust//rust/settings:pipelined_compilation

When set, this flag causes rustc to emit *.rmeta files and use them for rlib -> rlib dependencies.

While this involves one extra (short) rustc invocation to build the rmeta file, it allows library dependencies to be unlocked much sooner, increasing parallelism during compilation.

rename_first_party_crates

--@rules_rust//rust/settings:rename_first_party_crates

A flag controlling whether to rename first-party crates such that their names encode the Bazel package and target name, instead of just the target name.

First-party vs. third-party crates are identified using the value of @rules_rust//settings:third_party_dir.

rustc_output_diagnostics

--@rules_rust//rust/settings:rustc_output_diagnostics

This setting may be changed from the command line to generate rustc diagnostics.

rustfmt_toml

--@rules_rust//rust/settings:rustfmt_toml

This setting is used by the rustfmt rules. See https://bazelbuild.github.io/rules_rust/rust_fmt.html

Note that this setting is actually called rustfmt.toml.

third_party_dir

--@rules_rust//rust/settings:third_party_dir

A flag specifying the location of vendored third-party rust crates within this repository that must not be renamed when rename_first_party_crates is enabled.

Must be specified as a Bazel package, e.g. "//some/location/in/repo".

toolchain_generated_sysroot

--@rules_rust//rust/settings:toolchain_generated_sysroot

A flag to set rustc --sysroot flag to the sysroot generated by rust_toolchain.

unpretty

--@rules_rust//rust/settings:unpretty

use_real_import_macro

--@rules_rust//rust/settings:use_real_import_macro

A flag to control whether rust_library and rust_binary targets should implicitly depend on the real import macro, or on a no-op target.

Cargo settings

Definitions for all @rules_rust//cargo settings

cargo_manifest_dir_filename_suffixes_to_retain

--@rules_rust//cargo/settings:cargo_manifest_dir_filename_suffixes_to_retain

A flag which determines what files are retained in CARGO_MANIFEST_DIR directories that are created in CargoBuildScriptRun actions.

debug_std_streams_output_group

--@rules_rust//cargo/settings:debug_std_streams_output_group

A flag which adds a streams output group to cargo_build_script targets that contain the raw stderr and stdout streams from the build script.

experimental_symlink_execroot

--@rules_rust//cargo/settings:experimental_symlink_execroot

A flag for which causes cargo_build_script to symlink the execroot of the action to the CARGO_MANIFEST_DIR where the scripts are run.

incompatible_runfiles_cargo_manifest_dir

--@rules_rust//cargo/settings:incompatible_runfiles_cargo_manifest_dir

A flag which causes cargo_build_script to write an explicit CARGO_MANFIEST_DIR directory from an action instead of using runfiles directories which cannot be passed to downstream actions.

https://github.com/bazelbuild/bazel/issues/15486

use_default_shell_env

--@rules_rust//cargo/settings:use_default_shell_env

A flag which controls the global default of ctx.actions.run.use_default_shell_env for cargo_build_script targets.

Rust Toolchains

Toolchain rules for Rust.

Rules

• rust_analyzer_toolchain
• rust_toolchain
• rustfmt_toolchain

rust_analyzer_toolchain

load("@rules_rust//rust:toolchain.bzl", "rust_analyzer_toolchain")

rust_analyzer_toolchain(name, proc_macro_srv, rustc, rustc_srcs)

A toolchain for rust-analyzer.

ATTRIBUTES

rust_toolchain

load("@rules_rust//rust:toolchain.bzl", "rust_toolchain")

rust_toolchain(name, allocator_library, binary_ext, cargo, cargo_clippy, clippy_driver, debug_info,
               default_edition, dylib_ext, env, exec_triple, experimental_link_std_dylib,
               experimental_use_cc_common_link, extra_exec_rustc_flags, extra_rustc_flags,
               extra_rustc_flags_for_crate_types, global_allocator_library, llvm_cov, llvm_profdata,
               llvm_tools, opt_level, per_crate_rustc_flags, rust_doc, rust_std, rustc, rustc_lib,
               rustfmt, staticlib_ext, stdlib_linkflags, strip_level, target_json, target_triple)

Declares a Rust toolchain for use.

This is for declaring a custom toolchain, eg. for configuring a particular version of rust or supporting a new platform.

Example:

Suppose the core rust team has ported the compiler to a new target CPU, called cpuX. This support can be used in Bazel by defining a new toolchain definition and declaration:

load('@rules_rust//rust:toolchain.bzl', 'rust_toolchain')

rust_toolchain(
    name = "rust_cpuX_impl",
    binary_ext = "",
    dylib_ext = ".so",
    exec_triple = "cpuX-unknown-linux-gnu",
    rust_doc = "@rust_cpuX//:rustdoc",
    rust_std = "@rust_cpuX//:rust_std",
    rustc = "@rust_cpuX//:rustc",
    rustc_lib = "@rust_cpuX//:rustc_lib",
    staticlib_ext = ".a",
    stdlib_linkflags = ["-lpthread", "-ldl"],
    target_triple = "cpuX-unknown-linux-gnu",
)

toolchain(
    name = "rust_cpuX",
    exec_compatible_with = [
        "@platforms//cpu:cpuX",
        "@platforms//os:linux",
    ],
    target_compatible_with = [
        "@platforms//cpu:cpuX",
        "@platforms//os:linux",
    ],
    toolchain = ":rust_cpuX_impl",
)

Then, either add the label of the toolchain rule to register_toolchains in the WORKSPACE, or pass it to the "--extra_toolchains" flag for Bazel, and it will be used.

See @rules_rust//rust:repositories.bzl for examples of defining the @rust_cpuX repository with the actual binaries and libraries.

ATTRIBUTES

rustfmt_toolchain

load("@rules_rust//rust:toolchain.bzl", "rustfmt_toolchain")

rustfmt_toolchain(name, rustc, rustc_lib, rustfmt)

A toolchain for rustfmt

ATTRIBUTES

Rust Repositories

Repository rules for defining Rust dependencies and toolchains.

Functions

• rules_rust_dependencies
• rust_analyzer_toolchain_repository
• rust_register_toolchains
• rust_repositories
• rust_repository_set
• rust_toolchain_repository

Repository Rules

• rust_toolchain_repository_proxy
• rust_toolchain_tools_repository

rules_rust_dependencies

load("@rules_rust//rust:repositories.bzl", "rules_rust_dependencies")

rules_rust_dependencies()

Dependencies used in the implementation of rules_rust.

rust_analyzer_toolchain_repository

load("@rules_rust//rust:repositories.bzl", "rust_analyzer_toolchain_repository")

rust_analyzer_toolchain_repository(name, version, exec_compatible_with, target_compatible_with,
                                   sha256s, urls, auth, netrc, auth_patterns)

Assemble a remote rust_analyzer_toolchain target based on the given params.

PARAMETERS

RETURNS

str: The name of a registerable rust_analyzer_toolchain.

rust_register_toolchains

load("@rules_rust//rust:repositories.bzl", "rust_register_toolchains")

rust_register_toolchains(dev_components, edition, allocator_library, global_allocator_library,
                         register_toolchains, rustfmt_version, rust_analyzer_version, sha256s,
                         extra_target_triples, extra_rustc_flags, extra_exec_rustc_flags, urls,
                         versions, aliases, hub_name, compact_windows_names, toolchain_triples,
                         rustfmt_toolchain_triples, extra_toolchain_infos)

Emits a default set of toolchains for Linux, MacOS, and Freebsd

Skip this macro and call the rust_repository_set macros directly if you need a compiler for other hosts or for additional target triples.

The sha256s attribute represents a dict associating tool subdirectories to sha256 hashes. As an example:

{
    "rust-1.46.0-x86_64-unknown-linux-gnu": "e3b98bc3440fe92817881933f9564389eccb396f5f431f33d48b979fa2fbdcf5",
    "rustfmt-1.4.12-x86_64-unknown-linux-gnu": "1894e76913303d66bf40885a601462844eec15fca9e76a6d13c390d7000d64b0",
    "rust-std-1.46.0-x86_64-unknown-linux-gnu": "ac04aef80423f612c0079829b504902de27a6997214eb58ab0765d02f7ec1dbc",
}

This would match for exec_triple = "x86_64-unknown-linux-gnu". If not specified, rules_rust pulls from a non-exhaustive list of known checksums..

See load_arbitrary_tool in @rules_rust//rust:repositories.bzl for more details.

PARAMETERS

rust_repositories

load("@rules_rust//rust:repositories.bzl", "rust_repositories")

rust_repositories(kwargs)

Deprecated: Use rules_rust_dependencies and rust_register_toolchains directly.

PARAMETERS

rust_repository_set

load("@rules_rust//rust:repositories.bzl", "rust_repository_set")

rust_repository_set(name, versions, exec_triple, target_settings, allocator_library,
                    global_allocator_library, extra_target_triples, rustfmt_version, edition,
                    dev_components, extra_rustc_flags, extra_exec_rustc_flags, opt_level, sha256s,
                    urls, auth, netrc, auth_patterns, register_toolchain, exec_compatible_with,
                    default_target_compatible_with, aliases, compact_windows_names)

Assembles a remote repository for the given toolchain params, produces a proxy repository to contain the toolchain declaration, and registers the toolchains.

PARAMETERS

RETURNS

dict[str, dict]: A dict of informations about all generated toolchains.

rust_toolchain_repository

load("@rules_rust//rust:repositories.bzl", "rust_toolchain_repository")

rust_toolchain_repository(name, version, exec_triple, target_triple, exec_compatible_with,
                          target_compatible_with, target_settings, channel, allocator_library,
                          global_allocator_library, rustfmt_version, edition, dev_components,
                          extra_rustc_flags, extra_exec_rustc_flags, opt_level, sha256s, urls, auth,
                          netrc, auth_patterns)

Assembles a remote repository for the given toolchain params, produces a proxy repository to contain the toolchain declaration, and registers the toolchains.

PARAMETERS

RETURNS

dict[str, str]: Information about the registerable toolchain created by this rule.

rust_toolchain_repository_proxy

load("@rules_rust//rust:repositories.bzl", "rust_toolchain_repository_proxy")

rust_toolchain_repository_proxy(name, exec_compatible_with, repo_mapping, target_compatible_with,
                                target_settings, toolchain, toolchain_type)

Generates a toolchain-bearing repository that declares the toolchains from some other rust_toolchain_repository.

ATTRIBUTES

rust_toolchain_tools_repository

load("@rules_rust//rust:repositories.bzl", "rust_toolchain_tools_repository")

rust_toolchain_tools_repository(name, allocator_library, auth, auth_patterns, dev_components,
                                edition, exec_triple, extra_exec_rustc_flags, extra_rustc_flags,
                                global_allocator_library, netrc, opt_level, repo_mapping,
                                rustfmt_version, sha256s, target_triple, urls, version)

Composes a single workspace containing the toolchain components for compiling on a given platform to a series of target platforms.

A given instance of this rule should be accompanied by a toolchain_repository_proxy invocation to declare its toolchains to Bazel; the indirection allows separating toolchain selection from toolchain fetching.

ATTRIBUTES

External Dependencies

crate_universe (crate_universe bzlmod) is a tool built into rules_rust that can be used to fetch dependencies.

Crate Universe

Crate Universe is a set of Bazel rule for generating Rust targets using Cargo.

This doc describes using crate_universe with bzlmod.

If you're using a WORKSPACE file, please see the WORKSPACE equivalent of this doc.

There are some examples of using crate_universe with bzlmod in the example folder.

Table of Contents

1. Setup
2. Dependencies
   • Cargo Workspace
   • Direct Packages
   • Vendored Dependencies
3. Crate reference
   • from_cargo
   • from_specs

Setup

To use rules_rust in a project using bzlmod, add the following to your MODULE.bazel file:

bazel_dep(name = "rules_rust", version = "0.49.3")

You find the latest version on the release page.

After adding rules_rust in your MODULE.bazel, set the following to begin using crate_universe:

crate = use_extension("@rules_rust//crate_universe:extensions.bzl", "crate")
//  # ... Dependencies
use_repo(crate, "crates")

Dependencies

There are three different ways to declare dependencies in your MODULE.

1. Cargo workspace
2. Direct Dependencies
3. Vendored Dependencies

Cargo Workspaces

One of the simpler ways to wire up dependencies would be to first structure your project into a Cargo workspace. The crates_repository rule can ingest a root Cargo.toml file and generate Bazel dependencies from there. You find a complete example in the in the example folder.

crate = use_extension("@rules_rust//crate_universe:extensions.bzl", "crate")

crate.from_cargo(
    name = "crates",
    cargo_lockfile = "//:Cargo.lock",
    manifests = ["//:Cargo.toml"],
)
use_repo(crate, "crates")

The generated crates_repository contains helper macros which make collecting dependencies for Bazel targets simpler. Notably, the all_crate_deps and aliases macros ( see Dependencies API) commonly allow the Cargo.toml files to be the single source of truth for dependencies. Since these macros come from the generated repository, the dependencies and alias definitions they return will automatically update BUILD targets. In your BUILD files, you use these macros for a Rust library as shown below:

load("@crate_index//:defs.bzl", "aliases", "all_crate_deps")
load("@rules_rust//rust:defs.bzl", "rust_library", "rust_test")

rust_library(
    name = "lib",
    aliases = aliases(),
    deps = all_crate_deps(
        normal = True,
    ),
    proc_macro_deps = all_crate_deps(
        proc_macro = True,
    ),
)

rust_test(
    name = "unit_test",
    crate = ":lib",
    aliases = aliases(
        normal_dev = True,
        proc_macro_dev = True,
    ),
    deps = all_crate_deps(
        normal_dev = True,
    ),
    proc_macro_deps = all_crate_deps(
        proc_macro_dev = True,
    ),
)

For a Rust binary that does not depend on any macro, use the following configuration in your build file:

rust_binary(
    name = "bin",
    srcs = ["src/main.rs"],
    deps = all_crate_deps(normal = True),
)

You have to repin before your first build to ensure all Bazel targets for the macros are generated.

Dependency syncing and updating is done in the repository rule which means it's done during the analysis phase of builds. As mentioned in the environments variable table above, the CARGO_BAZEL_REPIN (or REPIN) environment variables can be used to force the rule to update dependencies and potentially render a new lockfile. Given an instance of this repository rule named crates, the easiest way to repin dependencies is to run:

CARGO_BAZEL_REPIN=1 bazel sync --only=crates

This will result in all dependencies being updated for a project. The CARGO_BAZEL_REPIN environment variable can also be used to customize how dependencies are updated. For more details about repin, please refer to the documentation.

Direct Dependencies

In cases where Rust targets have heavy interactions with other Bazel targets (Cc, Proto, etc.), maintaining Cargo.toml files may have diminishing returns as things like rust-analyzer begin to be confused about missing targets or environment variables defined only in Bazel. In situations like this, it may be desirable to have a “Cargo free” setup. You find an example in the in the example folder.

crates_repository supports this through the packages attribute, as shown below.

crate = use_extension("@rules_rust//crate_universe:extensions.bzl", "crate")

crate.spec(package = "serde", features = ["derive"], version = "1.0")
crate.spec(package = "serde_json", version = "1.0")
crate.spec(package = "tokio", default_features=False, features = ["macros", "net", "rt-multi-thread"], version = "1.38")

crate.from_specs()
use_repo(crate, "crates")

Consuming dependencies may be more ergonomic in this case through the aliases defined in the new repository. In your BUILD files, you use direct dependencies as shown below:

rust_binary(
    name = "bin",
    crate_root = "src/main.rs",
    srcs = glob([
        "src/*.rs",
    ]),
    deps = [
        # External crates
        "@crates//:serde",
        "@crates//:serde_json",
        "@crates//:tokio",
    ],
    visibility = ["//visibility:public"],
)

Notice, direct dependencies do not need repining. Only a cargo workspace needs updating whenever the underlying Cargo.toml file changed.

Vendored Dependencies

In some cases, it is require that all external dependencies are vendored, meaning downloaded and stored in the workspace. This helps, for example, to conduct licence scans, apply custom patches, or to ensure full build reproducibility since no download error could possibly occur. You find a complete example in the in the example folder.

For the setup, you need to add the skylib in addition to the rust rules to your MODUE.bazel.

module(
    name = "deps_vendored",
    version = "0.0.0"
)
###############################################################################
# B A Z E L  C E N T R A L  R E G I S T R Y # https://registry.bazel.build/
###############################################################################
# https://github.com/bazelbuild/bazel-skylib/releases/
bazel_dep(name = "bazel_skylib", version = "1.7.1")

# https://github.com/bazelbuild/rules_rust/releases
bazel_dep(name = "rules_rust", version = "0.49.3")

###############################################################################
# T O O L C H A I N S
###############################################################################

# Rust toolchain
RUST_EDITION = "2021"
RUST_VERSION = "1.80.1"

rust = use_extension("@rules_rust//rust:extensions.bzl", "rust")
rust.toolchain(
    edition = RUST_EDITION,
    versions = [RUST_VERSION],
)
use_repo(rust, "rust_toolchains")
register_toolchains("@rust_toolchains//:all")

###############################################################################
# R U S T  C R A T E S
###############################################################################
crate = use_extension("@rules_rust//crate_universe:extensions.bzl", "crate")

Note, it is important to load the crate_universe rules otherwise you will get an error as the rule set is needed in the vendored target.

Assuming you have a package called basic in which you want to vendor dependencies, then you create a folder basic/3rdparty. The folder name can be arbitrary, but by convention, its either thirdparty or 3rdparty to indicate vendored dependencies. In the 3rdparty folder, you add a target crates_vendor to declare your dependencies to vendor. In the example, we vendor a specific version of bzip2.

load("@rules_rust//crate_universe:defs.bzl", "crate", "crates_vendor")

crates_vendor(
    name = "crates_vendor",
    annotations = {
        "bzip2-sys": [crate.annotation(
            gen_build_script = True,
        )],
    },
    cargo_lockfile = "Cargo.Bazel.lock",
    generate_build_scripts = False,
    mode = "remote",
    packages = {
        "bzip2": crate.spec(
            version = "=0.3.3",
        ),
    },
    repository_name = "basic",
    tags = ["manual"],
)

Next, you have to run Cargo build to generate a Cargo.lock file with all resolved dependencies. Then, you rename Cargo.lock to Cargo.Bazel.lock and place it inside the basic/3rdparty folder.

At this point, you have the following folder and files:

basic
    ├── 3rdparty
    │   ├── BUILD.bazel
    │   ├── Cargo.Bazel.lock

Now you can run the crates_vendor target:

bazel run //basic/3rdparty:crates_vendor

This generates a crate folders with all configurations for the vendored dependencies.

basic
    ├── 3rdparty
    │   ├── cratea
    │   ├── BUILD.bazel
    │   ├── Cargo.Bazel.lock

Suppose you have an application in basic/src that is defined in basic/BUILD.bazel and that depends on a vendored dependency. You find a list of all available vendored dependencies in the BUILD file of the generated folder: basic/3rdparty/crates/BUILD.bazel You declare a vendored dependency in you target as following:

load("@rules_rust//rust:defs.bzl", "rust_binary")

rust_binary(
    name = "hello_sys",
    srcs = ["src/main.rs"],
    deps = ["//basic/3rdparty/crates:bzip2"],
    visibility = ["//visibility:public"],
)

Note, the vendored dependency is not yet accessible because you have to define first how to load the vendored dependencies. For that, you first create a file sys_deps.bzl and add the following content:

# rename the default name "crate_repositories" in case you import multiple vendored folders.
load("//basic/3rdparty/crates:defs.bzl", basic_crate_repositories = "crate_repositories")

def sys_deps():
    # Load the vendored dependencies
    basic_crate_repositories()

This is straightforward, you import the generated crate_repositories from the crates folder, rename it to avoid name clashes in case you import from multiple vendored folders, and then just load the vendored dependencies.

In a WORKSPACE configuration, you would just load and call sys_deps(), but in a MODULE configuration, you cannot do that. Instead, you create a new file WORKSPACE.bzlmod and add the following content.

load("//:sys_deps.bzl", "sys_deps")
sys_deps()

Now, you can build the project as usual.

There are some more examples of using crate_universe with bzlmod in the example folder.

crate

crate = use_extension("@rules_rust//crate_universe:docs_bzlmod.bzl", "crate")
crate.annotation(deps, data, additive_build_file, additive_build_file_content, alias_rule,
                 build_script_data, build_script_data_glob, build_script_deps, build_script_env,
                 build_script_proc_macro_deps, build_script_rundir, build_script_rustc_env,
                 build_script_toolchains, build_script_tools, compile_data, compile_data_glob, crate,
                 crate_features, data_glob, disable_pipelining, extra_aliased_targets,
                 gen_all_binaries, gen_binaries, gen_build_script, override_target_bin,
                 override_target_build_script, override_target_lib, override_target_proc_macro,
                 patch_args, patch_tool, patches, proc_macro_deps, repositories, rustc_env,
                 rustc_env_files, rustc_flags, shallow_since, version)
crate.from_cargo(name, cargo_config, cargo_lockfile, generate_binaries, generate_build_scripts,
                 manifests, splicing_config, supported_platform_triples)
crate.from_specs(name, cargo_config, generate_binaries, generate_build_scripts, splicing_config,
                 supported_platform_triples)
crate.spec(artifact, branch, default_features, features, git, lib, package, rev, tag, version)

Crate universe module extensions.

TAG CLASSES

annotation

Attributes

from_cargo

Generates a repo @crates from a Cargo.toml / Cargo.lock pair.

Attributes

from_specs

Generates a repo @crates from the defined spec tags.

Attributes

spec

Attributes

Crate Universe

Crate Universe is a set of Bazel rule for generating Rust targets using Cargo.

This doc describes using crate_universe from a WORKSPACE file.

If you're using bzlmod, please see the bzlmod equivalent of this doc.

Setup

After loading rules_rust in your workspace, set the following to begin using crate_universe:

load("@rules_rust//crate_universe:repositories.bzl", "crate_universe_dependencies")

crate_universe_dependencies()

Note that if the current version of rules_rust is not a release artifact, you may need to set additional flags such as bootstrap = True on the crate_universe_dependencies call above or crates_repository::generator_urls in uses of crates_repository.

Rules

• crates_repository
• crates_vendor

Utility Macros

• crate_universe_dependencies
• crate.annotation
• crate.select
• crate.spec
• crate.workspace_member
• render_config
• splicing_config

Workflows

The crates_repository rule (the primary repository rule of rules_rust's cargo support) supports a number of different ways users can express and organize their dependencies. The most common are listed below though there are more to be found in the ./examples/crate_universe directory.

Cargo Workspaces

One of the simpler ways to wire up dependencies would be to first structure your project into a Cargo workspace. The crates_repository rule can ingest a root Cargo.toml file and generate dependencies from there.

load("@rules_rust//crate_universe:defs.bzl", "crates_repository")

crates_repository(
    name = "crate_index",
    cargo_lockfile = "//:Cargo.lock",
    lockfile = "//:Cargo.Bazel.lock",
    manifests = ["//:Cargo.toml"],
)

load("@crate_index//:defs.bzl", "crate_repositories")

crate_repositories()

The generated crates_repository contains helper macros which make collecting dependencies for Bazel targets simpler. Notably, the all_crate_deps and aliases macros (see Dependencies API) commonly allow the Cargo.toml files to be the single source of truth for dependencies. Since these macros come from the generated repository, the dependencies and alias definitions they return will automatically update BUILD targets.

load("@crate_index//:defs.bzl", "aliases", "all_crate_deps")
load("@rules_rust//rust:defs.bzl", "rust_library", "rust_test")

rust_library(
    name = "lib",
    aliases = aliases(),
    deps = all_crate_deps(
        normal = True,
    ),
    proc_macro_deps = all_crate_deps(
        proc_macro = True,
    ),
)

rust_test(
    name = "unit_test",
    crate = ":lib",
    aliases = aliases(
        normal_dev = True,
        proc_macro_dev = True,
    ),
    deps = all_crate_deps(
        normal_dev = True,
    ),
    proc_macro_deps = all_crate_deps(
        proc_macro_dev = True,
    ),
)

Direct Packages

In cases where Rust targets have heavy interractions with other Bazel targests (Cc, Proto, etc.), maintaining Cargo.toml files may have deminishing returns as things like rust-analyzer begin to be confused about missing targets or environment variables defined only in Bazel. In workspaces like this, it may be desirable to have a "Cargo free" setup. crates_repository supports this through the packages attribute.

load("@rules_rust//crate_universe:defs.bzl", "crate", "crates_repository", "render_config")

crates_repository(
    name = "crate_index",
    cargo_lockfile = "//:Cargo.lock",
    lockfile = "//:Cargo.Bazel.lock",
    packages = {
        "async-trait": crate.spec(
            version = "0.1.51",
        ),
        "mockall": crate.spec(
            version = "0.10.2",
        ),
        "tokio": crate.spec(
            version = "1.12.0",
        ),
    },
    # Setting the default package name to `""` forces the use of the macros defined in this repository
    # to always use the root package when looking for dependencies or aliases. This should be considered
    # optional as the repository also exposes alises for easy access to all dependencies.
    render_config = render_config(
        default_package_name = ""
    ),
)

load("@crate_index//:defs.bzl", "crate_repositories")

crate_repositories()

Consuming dependencies may be more ergonomic in this case through the aliases defined in the new repository.

load("@rules_rust//rust:defs.bzl", "rust_library", "rust_test")

rust_library(
    name = "lib",
    deps = [
        "@crate_index//:tokio",
    ],
    proc_macro_deps = [
        "@crate_index//:async-trait",
    ],
)

rust_test(
    name = "unit_test",
    crate = ":lib",
    deps = [
        "@crate_index//:mockall",
    ],
)

Binary dependencies

Neither of the above approaches supports depending on binary-only packages.

In order to depend on a Cargo package that contains binaries and no library, you will need to do one of the following:

• Fork the package to add an empty lib.rs, which makes the package visible to Cargo metadata and compatible with the above approaches;

• Or handwrite your own build target for the binary, use http_archive to import its source code, and use crates_repository to make build targets for its dependencies. This is demonstrated below using the rustfilt crate as an example.

# in WORKSPACE.bazel

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "rustfilt",
    build_file = "//rustfilt:BUILD.rustfilt.bazel",
    sha256 = "c8d748b182c8f95224336d20dcc5609598af612581ce60cfb29da4dc8d0091f2",
    strip_prefix = "rustfilt-0.2.1",
    type = "tar.gz",
    urls = ["https://static.crates.io/crates/rustfilt/rustfilt-0.2.1.crate"],
)

load("@rules_rust//crate_universe:defs.bzl", "crates_repository")

crates_repository(
    name = "rustfilt_deps",
    cargo_lockfile = "//rustfilt:Cargo.lock",
    manifests = ["@rustfilt//:Cargo.toml"],
)

load("@rustfilt_deps//:defs.bzl", rustfilt_deps = "crate_repositories")

rustfilt_deps()

# in rustfilt/BUILD.rustfilt.bazel

load("@rules_rust//rust:defs.bzl", "rust_binary")

rust_binary(
    name = "rustfilt",
    srcs = glob(["src/**/*.rs"]),
    edition = "2018",
    deps = [
        "@rustfilt_deps//:clap",
        "@rustfilt_deps//:lazy_static",
        "@rustfilt_deps//:regex",
        "@rustfilt_deps//:rustc-demangle",
    ],
)

If you use either crates_repository or crates_vendor to depend on a Cargo package that contains both a library crate and binaries, by default only the library gets made available to Bazel. To generate Bazel targets for the binary crates as well, you must opt in to it with an annotation on the package:

load("@rules_rust//crate_universe:defs.bzl", "crates_repository", "crate")

crates_repository(
    name = "crate_index",
    annotations = {
        "thepackage": [crate.annotation(
            gen_binaries = True,
            # Or, to expose just a subset of the package's binaries by name:
            gen_binaries = ["rustfilt"],
        )],
    },
    # Or, to expose every binary of every package:
    generate_binaries = True,
    ...
)

Dependencies API

After rendering dependencies, convenience macros may also be generated to provide convenient accessors to larger sections of the dependency graph.

• aliases
• crate_deps
• all_crate_deps
• crate_repositories

Building crates with complicated dependencies

Some crates have build.rs scripts which are complicated to run. Typically these build C++ (or other languages), or attempt to find pre-installed libraries on the build machine.

There are a few approaches to making sure these run:

Some things work without intervention

Some build scripts will happily run without any support needed.

rules_rust already supplies a configured C++ toolchain as input to build script execution, and sets variables like CC, CXX, LD, LDFLAGS, etc as needed. Many crates which invoke a compiler with the default environment, or forward these env vars, will Just Work (e.g. if using cc-rs).

rules_rust is open to PRs which make build scripts more likely to work by default with intervention assuming they're broadly applicable (e.g. setting extra widely-known env vars is probably fine, wiring up additional toolchains like cmake that aren't present by default for most Bazel users probably isn't).

Supplying extra tools to build

Some build scripts can be made to work by pulling in some extra files and making them available to the build script.

Commonly this is done by passing the file to the build_script_data annotation for the crate, and using build_script_env to tell the build script where the file is. That env var may often use $(execroot) to get the path to the label, or $${pwd}/ as a prefix if the path given is relative to the execroot (as will frequently happen when using a toolchain).A

There is an example of this in the "complicated dependencies" section of https://github.com/bazelbuild/rules_rust/blob/main/examples/crate_universe/WORKSPACE.bazel which builds libz-ng-sys.

Building with Bazel and supplying via an override

Some build scripts have hooks to allow replacing parts that are complicated to build with output prepared by Bazel.

We can use those hooks by specifying paths (generally using the build_script_data and build_script_env annotations) and pointing them at labels which Bazel will then build. These env vars may often use $(execroot) to get the path to the label, or $${pwd}/ as a prefix if the path given is relative to the execroot (as will frequently happen when using a toolchain).

There is an example of this in the "complicated dependencies" section of https://github.com/bazelbuild/rules_rust/blob/main/examples/crate_universe/WORKSPACE.bazel which builds boring-sys.

crates_vendor

load("@rules_rust//crate_universe:docs_workspace.bzl", "crates_vendor")

crates_vendor(name, annotations, bazel, buildifier, cargo_bazel, cargo_config, cargo_lockfile,
              generate_binaries, generate_build_scripts, generate_target_compatible_with, manifests,
              mode, packages, render_config, repository_name, splicing_config,
              supported_platform_triples, vendor_path)

A rule for defining Rust dependencies (crates) and writing targets for them to the current workspace. This rule is useful for users whose workspaces are expected to be consumed in other workspaces as the rendered BUILD files reduce the number of workspace dependencies, allowing for easier loads. This rule handles all the same workflows crate_universe rules do.

Example:

Given the following workspace structure:

[workspace]/
    WORKSPACE
    BUILD
    Cargo.toml
    3rdparty/
        BUILD
    src/
        main.rs

The following is something that'd be found in 3rdparty/BUILD:

load("@rules_rust//crate_universe:defs.bzl", "crates_vendor", "crate")

crates_vendor(
    name = "crates_vendor",
    annotations = {
        "rand": [crate.annotation(
            default_features = False,
            features = ["small_rng"],
        )],
    },
    cargo_lockfile = "//:Cargo.Bazel.lock",
    manifests = ["//:Cargo.toml"],
    mode = "remote",
    vendor_path = "crates",
    tags = ["manual"],
)

The above creates a target that can be run to write BUILD files into the 3rdparty directory next to where the target is defined. To run it, simply call:

bazel run //3rdparty:crates_vendor

Repinning / Updating Dependencies

Repinning dependencies is controlled by both the CARGO_BAZEL_REPIN environment variable or the --repin flag to the crates_vendor binary. To update dependencies, simply add the flag ro your bazel run invocation.

bazel run //3rdparty:crates_vendor -- --repin

Under the hood, --repin will trigger a cargo update call against the generated workspace. The following table describes how to control particular values passed to the cargo update command.

ATTRIBUTES

aliases

load("@rules_rust//crate_universe:docs_workspace.bzl", "aliases")

aliases(normal, normal_dev, proc_macro, proc_macro_dev, build, build_proc_macro, package_name)

Produces a map of Crate alias names to their original label

If no dependency kinds are specified, normal and proc_macro are used by default. Setting any one flag will otherwise determine the contents of the returned dict.

PARAMETERS

RETURNS

dict: The aliases of all associated packages

all_crate_deps

load("@rules_rust//crate_universe:docs_workspace.bzl", "all_crate_deps")

all_crate_deps(normal, normal_dev, proc_macro, proc_macro_dev, build, build_proc_macro,
               package_name)

Finds the fully qualified label of all requested direct crate dependencies for the package where this macro is called.

If no parameters are set, all normal dependencies are returned. Setting any one flag will otherwise impact the contents of the returned list.

PARAMETERS

RETURNS

list: A list of labels to generated rust targets (str)

crate.annotation

load("@rules_rust//crate_universe:docs_workspace.bzl", "crate")

crate.annotation(version, additive_build_file, additive_build_file_content, alias_rule,
                 build_script_compile_data, build_script_data, build_script_tools,
                 build_script_data_glob, build_script_deps, build_script_env,
                 build_script_proc_macro_deps, build_script_rundir, build_script_rustc_env,
                 build_script_toolchains, build_script_use_default_shell_env, compile_data,
                 compile_data_glob, crate_features, data, data_glob, deps, extra_aliased_targets,
                 gen_binaries, disable_pipelining, gen_build_script, patch_args, patch_tool, patches,
                 proc_macro_deps, rustc_env, rustc_env_files, rustc_flags, shallow_since,
                 override_targets)

A collection of extra attributes and settings for a particular crate

PARAMETERS

RETURNS

string: A json encoded string containing the specified version and separately all other inputs.

crate.select

load("@rules_rust//crate_universe:docs_workspace.bzl", "crate")

crate.select(common, selects)

A Starlark Select for crate.annotation().

PARAMETERS

RETURNS

struct: A struct representing the Starlark Select.

crate.spec

load("@rules_rust//crate_universe:docs_workspace.bzl", "crate")

crate.spec(package, version, artifact, lib, default_features, features, git, branch, tag, rev)

A constructor for a crate dependency.

See specifying dependencies in the Cargo book for more details.

PARAMETERS

RETURNS

string: A json encoded string of all inputs

crate.workspace_member

load("@rules_rust//crate_universe:docs_workspace.bzl", "crate")

crate.workspace_member(version, sha256)

Define information for extra workspace members

PARAMETERS

RETURNS

string: A json encoded string of all inputs

crate_deps

load("@rules_rust//crate_universe:docs_workspace.bzl", "crate_deps")

crate_deps(deps, package_name)

Finds the fully qualified label of the requested crates for the package where this macro is called.

PARAMETERS

RETURNS

list: A list of labels to generated rust targets (str)

crate_repositories

load("@rules_rust//crate_universe:docs_workspace.bzl", "crate_repositories")

crate_repositories()

A macro for defining repositories for all generated crates.

RETURNS

A list of repos visible to the module through the module extension.

crate_universe_dependencies

load("@rules_rust//crate_universe:docs_workspace.bzl", "crate_universe_dependencies")

crate_universe_dependencies(rust_version, bootstrap, kwargs)

Define dependencies of the cargo-bazel Rust target

PARAMETERS

RETURNS

list[struct(repo=str, is_dev_dep=bool)]: A list of the repositories defined by this macro.

render_config

load("@rules_rust//crate_universe:docs_workspace.bzl", "render_config")

render_config(build_file_template, crate_label_template, crate_repository_template,
              crates_module_template, default_alias_rule, default_package_name,
              generate_target_compatible_with, platforms_template, regen_command, vendor_mode,
              generate_rules_license_metadata)

Various settings used to configure rendered outputs

The template parameters each support a select number of format keys. A description of each key can be found below where the supported keys for each template can be found in the parameter docs

PARAMETERS

RETURNS

string: A json encoded struct to match the Rust config::RenderConfig struct

splicing_config

load("@rules_rust//crate_universe:docs_workspace.bzl", "splicing_config")

splicing_config(resolver_version)

Various settings used to configure Cargo manifest splicing behavior.

PARAMETERS

RETURNS

str: A json encoded string of the parameters provided

crates_repository

load("@rules_rust//crate_universe:docs_workspace.bzl", "crates_repository")

crates_repository(name, annotations, cargo_config, cargo_lockfile,
                  compressed_windows_toolchain_names, generate_binaries, generate_build_scripts,
                  generate_target_compatible_with, generator, generator_sha256s, generator_urls,
                  isolated, lockfile, manifests, packages, quiet, render_config, repin_instructions,
                  repo_mapping, rust_toolchain_cargo_template, rust_toolchain_rustc_template,
                  rust_version, splicing_config, supported_platform_triples)

A rule for defining and downloading Rust dependencies (crates). This rule handles all the same workflows crate_universe rules do.

Environment Variables:

Example:

Given the following workspace structure:

[workspace]/
    WORKSPACE.bazel
    BUILD.bazel
    Cargo.toml
    Cargo.Bazel.lock
    src/
        main.rs

The following is something that'd be found in the WORKSPACE file:

load("@rules_rust//crate_universe:defs.bzl", "crates_repository", "crate")

crates_repository(
    name = "crate_index",
    annotations = {
        "rand": [crate.annotation(
            default_features = False,
            features = ["small_rng"],
        )],
    },
    cargo_lockfile = "//:Cargo.Bazel.lock",
    lockfile = "//:cargo-bazel-lock.json",
    manifests = ["//:Cargo.toml"],
    # Should match the version represented by the currently registered `rust_toolchain`.
    rust_version = "1.60.0",
)

The above will create an external repository which contains aliases and macros for accessing Rust targets found in the dependency graph defined by the given manifests.

NOTE: The cargo_lockfile and lockfile must be manually created. The rule unfortunately does not yet create it on its own. When initially setting up this rule, an empty file should be created and then populated by repinning dependencies.

Repinning / Updating Dependencies

Dependency syncing and updating is done in the repository rule which means it's done during the analysis phase of builds. As mentioned in the environments variable table above, the CARGO_BAZEL_REPIN (or REPIN) environment variables can be used to force the rule to update dependencies and potentially render a new lockfile. Given an instance of this repository rule named crate_index, the easiest way to repin dependencies is to run:

CARGO_BAZEL_REPIN=1 bazel sync --only=crate_index

This will result in all dependencies being updated for a project. The CARGO_BAZEL_REPIN environment variable can also be used to customize how dependencies are updated. The following table shows translations from environment variable values to the equivilant cargo update command that is called behind the scenes to update dependencies.

If the crates_repository is used multiple times in the same Bazel workspace (e.g. for multiple independent Rust workspaces), it may additionally be useful to use the CARGO_BAZEL_REPIN_ONLY environment variable, which limits execution of the repinning to one or multiple instances of the crates_repository rule via a comma-delimited allowlist:

CARGO_BAZEL_REPIN=1 CARGO_BAZEL_REPIN_ONLY=crate_index bazel sync --only=crate_index

ATTRIBUTES

ENVIRONMENT VARIABLES

This repository rule depends on the following environment variables:

• CARGO_BAZEL_GENERATOR_URL
• CARGO_BAZEL_GENERATOR_SHA256
• CARGO_BAZEL_REPIN
• REPIN
• CARGO_BAZEL_REPIN_ONLY
• CARGO_BAZEL_ISOLATED
• CARGO_BAZEL_DEBUG

Upstream Tooling

rules_rust manages versions of things like rustc. If you want to manually run upstream tooling configured at the versions, plugins and such that rules_rust has configured, rules_rust exposes these as targets in @rules_rust//tools/upstream_wrapper:

% bazel query @rules_rust//tools/upstream_wrapper
@rules_rust//tools/upstream_wrapper:cargo
@rules_rust//tools/upstream_wrapper:cargo_clippy
@rules_rust//tools/upstream_wrapper:rustc
@rules_rust//tools/upstream_wrapper:rustfmt

You can run them via bazel run, e.g. bazel run @rules_rust//tools/upstream_wrapper:cargo -- check.

Extensions

Bazel rules for interfacing with other rules and integrations with popular 3rd party tools.

Setup

The extension rules are released with each release of rules_rust (core) which can be found on the GitHub Releases page. We recommend using the latest release from that page.

Bzlmod

Note that rules_rust bzlmod support is still a work in progress. Most features should work, but bugs are more likely. This is not a desired end-state - please report (or better yet, help fix!) bugs you run into.

To use rules_rust extensions in a project using bzlmod, add the following to your MODULE.bazel file:

bazel_dep(name = "rules_rust_{EXTENSION}", version = "{VERSION}")

Don't forget to substitute in your desired release's version number and {EXTENSION} with the name of the desired extension. E.g.:

bazel_dep(name = "rules_rust_bindgen", version = "0.55.0")

WORKSPACE

To use rules_rust extensions in a project using a WORKSPACE file, add the following to your WORKSPACE file to add the external repositories for the Rust toolchain:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

# To find additional information on this release or newer ones visit:
# https://github.com/bazelbuild/rules_rust/releases
http_archive(
    name = "rules_rust_{EXTENSION}",
    # See releases page
)

# Refer to the documentation of the desired rules for how to load other necessary dependencies.

Don't forget to substitute in your desired release's version number, integrity hash, and {EXTENSION} with the name of the desired extension.

rules_rust_bindgen

These rules are for using Bindgen to generate Rust bindings to C (and some C++) libraries.

Rules

• rust_bindgen
• rust_bindgen_library
• rust_bindgen_toolchain

Setup

To use the Rust bindgen rules, add the following to your WORKSPACE file to add the external repositories for the Rust bindgen toolchain (in addition to the rust rules setup):

load("@rules_rust_bindgen//:repositories.bzl", "rust_bindgen_dependencies", "rust_bindgen_register_toolchains")

rust_bindgen_dependencies()

rust_bindgen_register_toolchains()

load("@rules_rust_bindgen//:transitive_repositories.bzl", "rust_bindgen_transitive_dependencies")

rust_bindgen_transitive_dependencies()

Bindgen aims to be as hermetic as possible so will end up building libclang from llvm-project from source. If this is found to be undesirable then no Bindgen related calls should be added to your WORKSPACE and instead users should define their own repositories using something akin to crate_universe and define their own toolchains following the instructions for rust_bindgen_toolchain.

rust_bindgen

load("@rules_rust_bindgen//:defs.bzl", "rust_bindgen")

rust_bindgen(name, bindgen_flags, cc_lib, clang_flags, header, merge_cc_lib_objects_into_rlib,
             wrap_static_fns)

Generates a rust source file from a cc_library and a header.

ATTRIBUTES

rust_bindgen_toolchain

load("@rules_rust_bindgen//:defs.bzl", "rust_bindgen_toolchain")

rust_bindgen_toolchain(name, bindgen, clang, default_rustfmt, libclang, libstdcxx)

The tools required for the rust_bindgen rule.

This rule depends on the bindgen binary crate, and it in turn depends on both a clang binary and the clang library. To obtain these dependencies, rust_bindgen_dependencies imports bindgen and its dependencies.

load("@rules_rust_bindgen//:defs.bzl", "rust_bindgen_toolchain")

rust_bindgen_toolchain(
    name = "bindgen_toolchain_impl",
    bindgen = "//my/rust:bindgen",
    clang = "//my/clang:clang",
    libclang = "//my/clang:libclang.so",
    libstdcxx = "//my/cpp:libstdc++",
)

toolchain(
    name = "bindgen_toolchain",
    toolchain = "bindgen_toolchain_impl",
    toolchain_type = "@rules_rust_bindgen//:toolchain_type",
)

This toolchain will then need to be registered in the current WORKSPACE. For additional information, see the Bazel toolchains documentation.

ATTRIBUTES

rust_bindgen_library

load("@rules_rust_bindgen//:defs.bzl", "rust_bindgen_library")

rust_bindgen_library(name, header, cc_lib, bindgen_flags, bindgen_features, clang_flags,
                     wrap_static_fns, kwargs)

Generates a rust source file for header, and builds a rust_library.

Arguments are the same as rust_bindgen, and kwargs are passed directly to rust_library.

PARAMETERS

rules_rust_mdbook

Bazel rules for mdBook.

Rules

• mdbook
• mdbook_server
• mdbook_toolchain

Setup

bzlmod

bazel_dep(name = "rules_rust_mdbook", version = "{SEE_RELEASE_NOTES}")

WORKSPACE

load("@rules_rust_mdbook//:repositories.bzl", "mdbook_register_toolchains", "rules_mdbook_dependencies")

rules_mdbook_dependencies()

mdbook_register_toolchains()

load("@rules_rust_mdbook//:repositories_transitive.bzl", "rules_mdbook_transitive_deps")

rules_mdbook_transitive_deps()

mdbook

load("@rules_rust_mdbook//:defs.bzl", "mdbook")

mdbook(name, srcs, book, plugins)

Rules to create book from markdown files using mdBook.

ATTRIBUTES

mdbook_server

load("@rules_rust_mdbook//:defs.bzl", "mdbook_server")

mdbook_server(name, book, hostname, port)

Spawn an mdbook server for a given mdbook target.

ATTRIBUTES

mdbook_toolchain

load("@rules_rust_mdbook//:defs.bzl", "mdbook_toolchain")

mdbook_toolchain(name, mdbook, plugins)

A mdBook toolchain.

ATTRIBUTES

rules_rust_prost

These build rules are used for building protobufs/gRPC in Rust with Bazel using Prost and Tonic

Rules

• rust_prost_library
• rust_prost_toolchain