-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Needless rebuilds when run with or without --workspace #9114
Comments
@rustbot modify labels +A-rebuild-detection +A-workspaces |
Error: The feature Please let |
I have been attempting to work around this and the behaviours I'm seeing make me think it may be related to #4463. |
A workaround in my environment is to always pass |
Yea, this is expected behavior in that the features chosen depend on which packages are being built. Closing as a duplicate of #4463. There are other workarounds such as a common package that forces the same features (see rustc-workspace-hack as an example). |
Enable triagebot's relabel functionality ### What does this PR try to resolve? This fixes the following failure that rustbot currently posts whenever someone tries to use "<b>`@</b><b>rustbot</b>` label" in this repository. > **Error**: The feature `relabel` is not enabled in this repository. > To enable it add its section in the `triagebot.toml` in the root of the repository. Unauthenticated relabel has been enabled in rust-lang/rust for nearly 4 years. People overwhelmingly use it in good faith. <br> ### How should we test and review this PR? Compare against https://github.com/rust-lang/rust/blob/1.66.0/triagebot.toml. Also skim through the 7 pages of labels on https://github.com/rust-lang/cargo/labels, whether it makes sense the ones I decided to allow arbitrary GitHub users to apply. <br> ### Additional information Attempted uses of "<b>`@</b><b>rustbot</b>` label", that failed, but this PR would allow: - #10343 (comment) - #10243 (comment) - #9982 (comment) - #9128 (comment) - #9067 (comment) - #8441 (comment) - #11432 (comment) - #8841 (comment) - #10820 (comment) - #10572 (comment) - #9114 (comment) - #8980 (comment) - #9064 (comment) - #8726 (comment) - #8089 (comment)
Problem
cargo rebuilds things if I switch between
cargo build
andcargo build --workspace
.Steps
git clone https://salsa.debian.org/iwj/otter
cd otter
git checkout c9b5a88d7a33a6e1eac22736be0a38c6815e1706
cargo build --workspace
cargo build
To repeat, restarting from after step 4 or 5:
touch src/updates.rs
Expected behaviour
The whole workspace including the toplevel package
otter
was built in step 4, so step 5 should not build anything and should be very quick.Actual behaviour
cargo rebuilds
otter
(including library and binaries) in step 5 (about six seconds on my laptop in a repeated test)Notes
Output of
cargo version
:The text was updated successfully, but these errors were encountered: