Addresses https://github.com/bazelbuild/rules_rust/issues/2661
If the workspace name is empty, the crate_module_template will use a
label like `Label(//<stuff>)` instead of `Label(@//<stuff>)`
Most of the changes in this are just regenerating the vendor'ed crates
in the examples. I ran the tests in all the relevant examples to ensure
they still worked.
This is similar to our `$(location)` expansion support for
`stdlib_linkflags`. We found ourselves needing this when defining a
custom rust dfsan-enabled toolchain. There, rustc needs an extra
`-Zsanitizer-dataflow-abilist=/path/to/abilist.txt` flag.
This patch lets us do this by specifying the abilist file in
`rust_stdlib_filegroup.srcs` and passing it as
`rust_toolchain.extra_rustc_flags =
["-Zsanitizer-dataflow-abilist=$(location :dfsan_abilist)"]`.
While looking into this, I noticed and fixed an issue: the sources of
the `rust_stdlib_filegroup` passed to `rust_toolchain.rust_std` weren't
made available downstream to the compile actions. I believe location
expansion was working before for `stdlib_linkflags` just because the
targets used in this location expansion were made available indirectly
e.g., implicitly by the underlying C++ toolchain, or via `rustc_lib`.
The `rust_stdlib_filegroup` rule would sometimes break when passing
`.rlib`-s originating from another package to `srcs`.
The root cause is the logic inside it that creates `.a` -> `.rlib`
symlinks, where the `.a` symlink is declared sibling of the `.rlib`.
Bazel only allows symlink siblings to be in the same package as the
rule.
This updates the logic to detect this and create an intermediary `.rlib`
under the rule's package, allowing the `.a` to be symlinked to that.
---------
Co-authored-by: scentini <rosica@google.com>
Add customizable instructions to re-pin the repository if required. Many
people have wrapper scripts for keeping dependencies up to date, and
would like to point users to that instead of the default.
This follows the logic of
https://github.com/bazelbuild/rules_jvm_external/pull/1000
---------
Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>
This allows using a shared (generally pre-built) protoc definition,
rather than needing to supply one via a label.
We allow (but deprecate) users to still bring along their own protoc as
a label, but if they want to do so, they will need to ensure they have
the correct repositories registered in order to build/bring their
protoc, rather than us setting them up by default.
This PR provides documentation of Bazelmod and several code examples
that addresses a number of issues related to Bazelmod.
Preview of the documentation:
https://github.com/marvin-hansen/rules_rust/blob/main/docs/crate_universe_bzlmod.md
First and foremost it paves the way for a meaningful update the Bazelmod
documentation that references these and existing code examples. This
touches at least the following issues:
* #2670
* #2181
The compile_opt example addresses or resolves:
* #515
* #2701
The musl_cross_compilling example addresses or resolves
* #390
* #276
The oci_container does not relate to any open issue,
although the tokio example in it gives a nice end to end example so
this definitely helps those looking for something non-trivial.
The proto example addresses or resolves:
* #2668
* #302
* #2534
* Possibly a few more if I were to search longer
Formalities
* I've signed the CLA
* I've signed all commits
---------
Signed-off-by: Marvin Hansen <marvin.hansen@gmail.com>
Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>
Currently, `rust_test_suite` is not capable of supporting integration
tests with shared modules. A very basic example is:
```
[crate]/
src/
lib.rs
tests/
integration_test_a.rs
integration_test_b.rs
util/
mod.rs
```
With `integration_test_a.rs` and `integration_test_b.rs` importing code
from `util`.
This PR adds a `shared_srcs` argument to `rust_test_suite`. That way, we
can finally compile and run those tests with:
```python
rust_test_suite(
name = "integrated_tests_suite",
srcs = glob(["tests/**"]),
shared_srcs = ["tests/util/mod.rs"],
deps = [":example_dep"],
)
```
According to the [migration
guide](https://bazel.build/external/migration), `WORKSPACE.bazel` is no
longer required with Bazel 6.3 or later. This updates `crate_universe`
to respect that, allowing `MODULE.bazel` to be the root marker of a
workspace, without requiring a `WORKSPACE` or `WORKSPACE.bazel`.
Happy to iterate on this.
This change updates the `rust_analyzer_aspect` to attempt to match
generated crate root sources to `srcs` inputs and use the the path of
the source file in place of the generated path. The generated path is
then added to `sources.include_dirs` for compatibility. The impact of
this can be seen in the following diff of the
`@rules_rust//:rust-project.json` file:
```diff
--- rust-project.old.json 2024-06-28 09:00:51
+++ rust-project.json 2024-06-28 09:04:43
@@ -821,10 +821,16 @@
},
{
"display_name": "libgensrc_with_crate_root",
- "root_module": "/private/var/tmp/_bazel_user/76282c66b0dfe3c5cb9a230bdc913a52/execroot/rules_rust/bazel-out/darwin_arm64-fastbuild/bin/test/generated_inputs/lib.rs",
+ "root_module": "test/generated_inputs/lib.rs",
"edition": "2018",
"deps": [],
"is_workspace_member": true,
+ "source": {
+ "include_dirs": [
+ "/private/var/tmp/_bazel_user/76282c66b0dfe3c5cb9a230bdc913a52/execroot/rules_rust/bazel-out/darwin_arm64-fastbuild/bin/test/generated_inputs"
+ ],
+ "exclude_dirs": []
+ },
"cfg": [
"test",
"debug_assertions"
@@ -850,10 +856,16 @@
...
...
...
```
closes https://github.com/bazelbuild/rules_rust/issues/2716
Previously the bzlmod symbols were not documented at all, and in places
they are different from the WORKSPACE versions.
This at least hosts both.
Fixes #2696
Fixes #2692
This fixes `rust_register_toolchains` to correctly call
`rust_toolchain_repository` with a list of `extra_rustc_flags`.
Previously, the `extra_rustc_flags` argument of
`rust_register_toolchains` was assumed (when set) to be a dict of
toolchain triple to list. With this change, a `list` parameter is used
for all toolchain triples.
Co-authored-by: UebelAndre <github@uebelandre.com>
This PR reduces the number of expensive module extension implementation
restarts in combination with multiple `from_cargo` configurations.
As each configuration processing calls `module_ctx.path` (which can and
will cause restarts), we executed _generate_hub_and_spokes (i.e.
`cargo-bazel`) _a lot_ and then threw that away on the next restart.
Triggering `module_ctx.path` early is therefore a significant
performance optimization.
On our repository, this gives us a 10sec speedup on module extension
processing (local M1 mac, nothing happening in parallel), see our
[MODULE.bazel](https://github.com/github/codeql/blob/main/MODULE.bazel)
if you're interested in what we're doing.
This excessive restarting also exposed an upstream bazel bug on Windows
2019, where bazel spuriously fails to clean up the working directory
(c.f. https://github.com/bazelbuild/bazel/issues/22710).
Co-authored-by: Daniel Wagner-Hall <dwagnerhall@apple.com>
This introduces the flag
`--@rules_rust//rust/settings:experimental_use_sh_toolchain_for_bootstrap_process_wrapper`
which can be used to embed the shell path from
`@bazel_tools//tools/sh:toolchain_type` in the rustc bootstrap process
wrapper.
Before this, if we re-generate all of the BUILD.bazel files for our
vendored deps, they are invalid because they only have BUILD.bazel files
and the globs present in them expect srcs.
First two commits are real changes, third commit is just a repin.
The ability to override crate targets when using crate_universe was
added here: https://github.com/bazelbuild/rules_rust/pull/2674
However, this change did not expose that functionality when using
bzlmod.
This change adds that functionality in. Because of the limited set of
options we have for dictionaries in tag classes, I had to split out
"override_targets" into four different options, each taking a Label.
I have added in an example based on the example given in #2674 , but
using bzlmod instead. I have also tested that example and found it to be
working.
The `cargo_build_script_runner` currently converts the keys from
`cargo:KEY=VALUE` metadata build script output lines into uppercase.
This is not completely correct, however, because Cargo converts those
keys to uppercase AND replaces dashes with underscores (effectively
doing a conversion to SCREAMING_SNAKE_CASE).
To verify that Cargo is indeed doing the dash-to-underscore conversion,
have a look at
10b7d38435/src/cargo/core/compiler/custom_build.rs (L46),
which is the code responsible for building the
`DEP_{crate-name}_{metadata-key}` env variables in Cargo. The code is
```rust
cmd.env(
&format!("DEP_{}_{}", super::envify(&name), super::envify(key)),
value,
);
```
where `super::envify()` is defined as
```rust
fn envify(s: &str) -> String {
s.chars()
.flat_map(|c| c.to_uppercase())
.map(|c| if c == '-' { '_' } else { c })
.collect()
}
```
This PR adds the dash-to-underscore conversion to
`cargo_build_script_runner`.
The toolchain_files() and current_rust_toolchain() rules return files
for the current 'exec' platform. This is perfecly reasonable if you want
to use these tools as part of ctx.actions.run(). But if you want to use
these as part of 'data = []' (runfiles), they must be built for the
target.
Fixes: https://github.com/bazelbuild/rules_rust/issues/2684
Allow external crates to be aliased to local targets
In some cases it may be desirable to alias a public crate to a locally
define rust_library target, even for dependencies of crates that are not
being overriden.
Support this use case by swapping out `alias` for `rust_library` when
a user overrides the target using an annotation.
---------
Co-authored-by: Daniel Wagner-Hall <dwagnerhall@apple.com>
Right now the runfiles directory only contains "data" that is attached
to a rust_binary() or one of its dependencies. This is inconsistent with
cc_binary() and go_binary(), which also include an `_solib_*/` directory
containing shared library dependencies.
When doing a plain 'bazel run' against the resulting executable, this is
not a noticeable issue. The reason being that the runtime dynamic linker
will use `${execroot}/_solib_*`. However, it does become a problem when
`pkg_tar(include_runfiles = True)` is used to construct an archive of
the binary so that it can be placed in a container image.
This change extends the runfiles gathering logic to merge all
LibraryToLink.dynamic_library files in there as well.
This PR shortens the path to the build script (potentially
significantly), which helps with long-path issues on Windows.
This change is motivated by the crate `tree-sitter-embedded-template`,
which has a too long path to the compiled build script otherwise, and
which then fails to build on Windows in a `bzlmod` setting.
Fixes https://github.com/bazelbuild/rules_rust/issues/2520.
The cargo build script name was used to automatically derive the cargo
package name, this now went into a separate override parameter that is
generated by the crate-universe tooling.
There's never two build scripts in a single crate, so I don't see how
having a single build script target with a single name would be a
problem.
This allows it to work with new-style toolchains that use action configs
(see https://github.com/bazelbuild/bazel/issues/22561).
It also allows you to specify a seperate C compiler and C++ compiler.
Modifies the default of `rustfmt_version` so that it uses the first
version in the `versions` list. If there are multiple versions given
then falls back to the original default of `DEFAULT_NIGHTLY_VERSION`.
We tripped over this where supply a single Rust version (non-nightly),
but started using nightly features in `rustfmt.toml` and could no longer
format directly with `cargo fmt`. This helped align the versions of both
toolchains.
---------
Co-authored-by: Daniel Wagner-Hall <dwagnerhall@apple.com>
Daniel Wagner-Hall