-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
clippy-driver acts as a bogus rustc wrapper #12697
Comments
(Not related to this bug itself, but AFAIK, as said in cuviper/autocfg#58 (comment), |
Ah, sorry for that -- fixed. |
FYI, Libc no longer compiles with with clippy-driver as a RUSTC_WRAPPER, since this MR: rust-lang/libc#3845. this crate is used everywhere. The problem appears to Libc could make their version parsing more sophisticated, but I think the proper fix is for clippy-driver to properly wrap rustc and not change behavior of For now, I'm working around by setting RUSTC_WORKSPACE_WRAPPER, instead of RUSTC_WRAPPER, with the path to my clippy-driver. Works pretty much the same, but bypasses the problem in libc. |
This came up in cuviper/autocfg#58, and may also become more relevant with rust-lang/cargo#13659 and djc/rustc-version-rs#45:
Apparently,
cargo clippy
setsclippy-driver
as RUSTC_WORKSPACE_WRAPPER, but that wrapper behaves incorrectly, i.e. it does not always properly forward everything to rustc:I am surprised that clippy-driver is even being set as RUSTC_WORKSPACE_WRAPPER; Miri (which has a similar problem to solve) does not do that. Instead cargo-miri sets itself as RUSTC_WRAPPER so that it can then dispatch to the driver as appropriate. Either way can work, but whatever is set as RUSTC_WRAPPER/RUSTC_WORKSPACE_WRAPPER should behave like a proper wrapper and not intercept
--version
queries.The text was updated successfully, but these errors were encountered: