Build std with panic = "abort" errors with a bunch of duplicated lang items

[xTachyon]

Code

[profile.release]
panic = "abort"

rustup run nightly-2023-09-17 cargo rustc -p dune --profile release -Z build-std=std,core --target x86_64-pc-windows-msvc

The nightly version is not important, it's only what I was testing on.

Current output

A bunch of these:

error[E0152]: duplicate lang item in crate `core`: `sized`.
  |
  = note: the lang item is first defined in crate `core` (which `std` depends on)
  = note: first definition in `core` loaded from \\?\D:\repos\dune\target\x86_64-pc-windows-msvc\release\deps\libcore-8e933d06c178c4de.rlib, \\?\D:\repos\dune\target\x86_64-pc-windows-msvc\release\deps\libcore-8e933d06c178c4de.rmeta
  = note: second definition in `core` loaded from \\?\C:\Users\tachyon\.rustup\toolchains\nightly-2023-08-17-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libcore-b86a9ba077d96bbb.rlib

Desired output

A nice message that said panic_abort must be included in build-std if compiled with panic = "abort".

Rationale and extra context

From @Nilstrieb:
rustc can't find a panic_abort in your self-built standard library, so it falls back to loading panic_abort from the sysroot. But that sysroot panic_abort then also brings in the rest of the sysroot, including core, so now you have two cores, one from your target dir and one from your sysroot. This is bad.

Other cases

No response

Anything else?

No response

[Noratrieb]

Probably makes sense to have a specialized error message when loading core twice.

[klensy]

rust-lang/wg-cargo-std-aware#56, rust-lang/wg-cargo-std-aware#29

[Enselic]

Triage: Since for this particular issue it is needed to parse Cargo.toml, I think this should be moved to the cargo repo, right? Cargo knows what is in Cargo.toml and what is passed to -Z build-std=..., so it knows when to report a nice error.

[Noratrieb]

I think it would make sense for cargo to not allow this, if it does have all the necessary knowledge. But it would also be nice for rustc to detect cases like this better (I've also encountered this in other cursed cases).

[Enselic]

I'm sure there are ways to improve the error message (although personally I think it is quite informative already), but as the original issue was written, I think it needs to be moved to the cargo project. Keeping the issue in this issue track makes the cargo people not see it.

If it was easy to file a corresponding high-quality issue intended for the rust repo I would do it, but unfortunately it's not clear to me how to write such an issue and make it high quality. For example: I lack awareness of a concrete example for easy reproduction without using cargo.

[SaltyKitkat]

I'm just curious that why we don't have panic related things rebuilt when using -Zbuild-std?

[Enselic]

@rustbot transfer cargo

[ehuss]

I'm going to close as this is generally a known problem tracked in rust-lang/wg-cargo-std-aware#29 and rust-lang/wg-cargo-std-aware#31.

[weihanglo]

And also #7359, which is exactly the same issue.