commit 8cb9059c90858224cc017cb6449a4ea631e54a5f
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

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.