commit | 8cb9059c90858224cc017cb6449a4ea631e54a5f | [log] [tgz] |
---|---|---|
author | Krasimir Georgiev <krasimir@google.com> | Mon Jan 03 18:35:53 2022 +0200 |
committer | GitHub <noreply@github.com> | Mon Jan 03 08:35:53 2022 -0800 |
tree | 9041ecd14939454891ab16f5a894008fe52e8959 | |
parent | 6630fd5b6b7fe143ea09f80f64dc20e3514495b4 [diff] |
mix in label in crate hash computation (#1083) Consider the situation where we have two variants of the same crate: ``` rust_library( name = "foo", srcs = ["foo.rs"], ) rust_library( name = "foo2", crate_name = "foo", srcs = ["foo.rs"], ) ``` A use case for this is for example when we want to define different variants of a crate using different feature sets, e.g., define a rustc_private non-std variant of a vendored crate of the standard library together with a more standard version of the vendored crate that requires the standard library. Currently, this is a fragile definition since the output rlib filename of both of these is the same, e.g., `libfoo-$HASH.rlib`, where `$HASH` is derived from the crate root source filename, in this case `foo.rs`. So whenever we have a Bazel query that includes both of these, the build may fail with errors like: ``` ERROR: file 'test/unit/crate_variants/libfoo-717083168.rlib' is generated by these conflicting actions: Label: //test/unit/crate_variants:foo2, //test/unit/crate_variants:foo ``` This patch reduces the risk of such output filename collisions by mixing in the rule label in the output hash calculation.
This repository provides rules for building Rust projects with Bazel.
General discussions and announcements take place in the GitHub Discussions, but there are additional places where community members gather to discuss rules_rust
.
Please refer to the full documentation.