./x.py clippy loads two different version of core

[Nicholas-Baron]

I am used to cargo clippy providing many good hints in other Rust projects. However, the equivalent here (./x.py clippy) does not complete after around 64,000 lines of output.

The output of a single clippy run.

[jyn514]

How useful is it to have 64,000 lines of clippy output? Consider using x.py clippy library/std or some other specific crate instead of the whole source tree.

[Nicholas-Baron]

@jyn514 Running ./x.py clippy library/std also leads to the same amount of lines.

Additionally, running rg 'error\[' -c on the file shows around 500 errors.
Most seen to be E0277: the size of values of type 'foo' cannot be known at compilation time.
Removing these may help see other errors.

[jyn514]

That sounds like it's just broken in general then, those are the errors you get by compiling with cargo check instead of x.py. You're definitely using x.py clippy, right?

[Nicholas-Baron]

Yes, I am running ./x.py clippy and getting these errors.
I have mostly resorted to using ./x.py check, but I do want to get the clippy option working.
Are there any details of my setup that would be helpful in diagnosing the issue?

[jyn514]

Ok, I can reproduce this locally. cc @Mark-Simulacrum, it looks like x.py clippy has been broken for some time:

$ ./x.py clippy library/std -v
Checking std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
running: "/home/joshua/rustc/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "clippy" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "8" "--release" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/home/joshua/rustc/library/test/Cargo.toml" "--message-format" "json-render-diagnostics" "--" "--cap-lints" "warn"

... many thousands of lines of output ...

error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `bool`.
  |
  = note: the lang item is first defined in crate `core` (which `getrandom` depends on)
  = note: first definition in `core` loaded from /home/joshua/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-2675a9a46b5cec89.rlib
  = note: second definition in `core` loaded from /home/joshua/rustc/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/libcore-04b26fe1c15aa843.rmeta

[Mark-Simulacrum]

Yeah, this is because clippy isn't being sent through the sysroot shim. I don't myself plan to invest time into fixing this, FWIW, but if someone wants to dig in I would figure out why clippy is behaving differently from rustc itself here. I suspect it's because we're shimming rustc with src/bootstrap/bin/rustc.rs and we need to do the same for clippy.

[jyn514]

@Mark-Simulacrum do you know why this requires a separate binary instead of passing --sysroot to cargo clippy?

running: "/home/joshua/rustc/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "clippy" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "8" "--release" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/home/joshua/rustc/library/test/Cargo.toml" "--message-format" "json-render-diagnostics" "--" "--cap-lints" "warn" "--sysroot" "/home/joshua/rustc/build/x86_64-unknown-linux-gnu/stage0-sysroot"
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `/home/joshua/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/clippy-driver /home/joshua/rustc/build/bootstrap/debug/rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (exit code: 1)
  --- stderr
  error: Option 'sysroot' given more than once

[jyn514]

Also that approach won't work anyway, there's no CLIPPY analogue of RUSTDOC: https://doc.rust-lang.org/cargo/reference/environment-variables.html

[Mark-Simulacrum]

Broadly speaking it probably doesn't but a separate binary usually makes things easier. We will want to add that env variable (I am surprised to hear it wasn't added initially), via a cargo patch.

[jyn514]

Broadly speaking it probably doesn't but a separate binary usually makes things easier

I'm surprised you say that, I find it makes things a lot more painful because it means you have to set all sorts of env variables if you want to debug an issue.

error: Option 'sysroot' given more than once

I found this is because rustc.rs is passing sysroot itself; fn args() is for arguments passed to all binaries, not just clippy:

rust/src/bootstrap/bin/rustc.rs

Lines 86 to 88 in 5118a51

	if !args.iter().any(|arg| arg == "--sysroot") {
	cmd.arg("--sysroot").arg(&sysroot);
	}

[jyn514]

That wasn't actually the issue, clippy is also setting sysroot: https://github.com/rust-lang/rust-clippy/blob/master/src/driver.rs#L354

[jyn514]

Ok, setting SYSROOT to the proper sysroot got me a ton further:

error[E0463]: can't find crate for `std`

error: could not compile `std`

I'm not sure why clippy is trying to dynamically load std from the sysroot ... @rust-lang/clippy do you know what's going on here?

[jyn514]

For context, this is while running on std itself, so std isn't available yet - it hasn't been compiled.

[jyn514]

Possibly related: rust-lang/rust-clippy#2874