Fix build-std collisions. #7860
Conversation
|
r? @Eh2406 (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
I'm reluctant to add the test, since it is somewhat fragile (it makes assumptions about how libstd currently works). I'm fine with removing it (or changing it), but I wanted to get feedback. Also, per the comment, there is a potential optimization here to set |
|
I agree yeah the test here is probably a bit too brittle to add, I'd be fine landing this without the test. I also think it's fine to be a bit conservative here and build the build dependencies twice. They build pretty quickly anyway and we can always optimize this a bit later if truly necessary (but I highly doubt this'll come up again!) r=me if you're still ok removing the tests, or r=me if you have changed your mind and would like to keep the test :) |
This is too dependent on the particulars of libstd.
|
Nah, it's fine, I just removed it. @bors r=alexcrichton |
|
📌 Commit acfb89a has been approved by |
bors
added
S-waiting-on-bors
Fix build-std collisions. `build-std` unit filenames can collide with user dependencies in some situations. In particular, `cc` as a build-dependency is likely to be exactly the same as a user's dep. This would result in the `cc` crate being built twice, but with the same filename, causing a collision. Other dependencies typically never collide because they have the `rustc-dep-of-std` feature, but build-dependencies do not. The solution here is to include `is_std` in the metadata hash. Fixes #7859.
|
☀️ Test successful - checks-azure |
build-stdunit filenames can collide with user dependencies in some situations. In particular,ccas a build-dependency is likely to be exactly the same as a user's dep. This would result in thecccrate being built twice, but with the same filename, causing a collision.Other dependencies typically never collide because they have the
rustc-dep-of-stdfeature, but build-dependencies do not.The solution here is to include
is_stdin the metadata hash.Fixes #7859.