Repository navigation
RUSTC_WORKSPACE_WRAPPER tracking issue #8143
Description
RUSTC_WORKSPACE_WRAPPER was added in #7533, primarily for clippy support, but could be useful for others.
Differences from RUSTC_WRAPPER:
- Only runs for workspace members.
- Path is included in the filename hash (which ensures these artifacts are cached separately from usage without the wrapper).
You can test drive this with cargo clippy -Zunstable-options on the latest nightly.
One of the primary benefits is that now cargo clippy can share the same cache with cargo check for non-workspace members.
Before stabilizing, some things to consider:
- Is this the right design?
- This doesn't help with wrapping only specific crates (like just the "primary" ones). Sometimes people want to only have clippy lints for the "root" crate, or for specific crates specified on the command-line (Limit to specific package in workspace, also excluding its dependencies rust-clippy#3025). With this change for clippy,
cargo clippy -p NAMEonly works for workspace members.- Cargo previously had an undocumented
CARGO_PRIMARY_PACKAGEenvironment variable, perhaps something like that could be used? - How should tools like clippy handle
-p non-member?
- Cargo previously had an undocumented
- RUSTC_WORKSPACE_WRAPPER doesn't currently work with sccache. How difficult would this be to fix?
- Some tools may want to use arguments with the wrapper. For example,
my-tool wrapperwould pass the "wrapper" argument tomy-toolto tell it is in wrapper mode. Currently the env vars do not allow passing in arguments. Alternatively, Cargo could set some special env var to inform the executable that it is being used as a wrapper.
cc @yaahc
Activity
ehuss commentedon Apr 25, 2020
One problem that I ran into is when running
cargo clippy --fixfor a specific package in a workspace, clippy still runs for all other workspace members. This means that any workspace dependency that has a deny-level clippy lint will cause the build to fail. This is essentially rust-lang/rust-clippy#3025.I'm not sure how important that is, but it seems like it would make adopting clippy in a larger workspace to be difficult (and make the
--fixflag especially difficult to start using). I don't really have any ideas for the UI to switch that behavior (other than some command-line flag or env-var?).pre-commit clippy bug workaround
Auto merge of #6188 - ebroto:primary_package, r=Manishearth
Auto merge of #6188 - ebroto:primary_package, r=flip1995
ehuss commentedon Dec 13, 2020
@ebroto I've noticed you've gotten some fixes landed in clippy recently 🎉 (sorry, I haven't been able to help review or push those through). Do you think it is time to go ahead and stabilize this? I don't think I have any specific objections (or at least can't think of a better design for this use case). If so, are you interested in working on a PR?
ebroto commentedon Dec 13, 2020
No problem! Your guidance here has been really helpful :)
I think so. We could improve the process of passing arguments to the wrapper (the current solution in Clippy is hacky), but I think that could be addressed separately, as landing this would really improve Clippy's usability in stable.
Yes! I'm not sure what's involved here but I can take a look at other tracking issues.
ehuss commentedon Dec 13, 2020
I think it should be pretty easy:
-Zunstable-optionsandmasquerade_as_nightly_cargo.build.rustc-workspace-wrapperto the config docs (mostly just copy-and-paste everywhere you seerustc-wrapper).Auto merge of #8976 - ebroto:rustc_workspace_wrapper, r=ehuss
luser commentedon Feb 11, 2021
Coming into this extremely late, but this doesn't seem terribly important. For CI usage I would expect projects to simply use
RUSTC_WRAPPER. For local builds, workspace crates have incremental compilation enabled by default and sccache declines to cache incremental compiles (because it would just do a worse job than rustc anyway), so there's no real motivation to want this to work.