Skip to content
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

Give a better error message for cargo check on libstd itself #76446

Closed
wants to merge 1 commit into from

Conversation

jyn514
Copy link
Member

@jyn514 jyn514 commented Sep 7, 2020

Previously, the errors looked like this:

$ cargo check
    Checking std v0.0.0 (/home/joshua/rustc/library/std)
error: duplicate lang item in crate `core`: `bool`.
  |
  = note: the lang item is first defined in crate `core` (which `std` depends on)
  = note: first definition in `core` loaded from /home/joshua/.local/lib/cargo/target/debug/deps/libcore-afaeeb022194dcf3.rmeta
  = note: second 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

error[E0119]: conflicting implementations of trait `ffi::c_str::CString::new::SpecIntoVec` for type `&str`:
   --> library/std/src/ffi/c_str.rs:392:9
    |
379 |         impl<T: Into<Vec<u8>>> SpecIntoVec for T {
    |         ---------------------------------------- first implementation here
...
392 |         impl SpecIntoVec for &'_ str {
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `&str`
    |
    = note: upstream crates may add a new impl of trait `core::convert::Into<alloc_crate::vec::Vec<u8>>` for type `&str` in future versions

error: aborting due to 119 previous errors; 93 warnings emitted

Now, they're much more helpful:

$ cargo check
   Compiling core v0.0.0 (/home/joshua/rustc2/library/core)
error: failed to run custom build command for `core v0.0.0 (/home/joshua/rustc2/library/core)`

Caused by:
  process didn't exit successfully: `/home/joshua/.local/lib/cargo/target/debug/build/core-ea3b18d34c1ee1c8/build-script-build` (exit code: 101)
  --- stderr
  error: you are attempting to build libcore without going through bootstrap
  help: use `x.py build --stage 0 library/std`, not `cargo build`
  help: use `x.py check`, not `cargo check`
  note: if you're sure you want to do this, use `RUSTC_BOOTSTRAP=0` or some other dummy value
  thread 'main' panicked at 'explicit panic', library/core/build.rs:7:9
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The metric here is 'did you set RUSTC_BOOTSTRAP'; if so, it's assumed
you know what you're doing and no error is given. It's very unlikely (or
at least should be!) that someone will have RUSTC_BOOTSTRAP globally
set, so I think this is a good heuristic.

Closes #76444.
r? @Mark-Simulacrum
cc @jix

@jyn514 jyn514 added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Sep 7, 2020
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 7, 2020
Previously, the errors looked like this:

```
$ cargo check
    Checking std v0.0.0 (/home/joshua/rustc/library/std)
error: duplicate lang item in crate `core`: `bool`.
  |
  = note: the lang item is first defined in crate `core` (which `std` depends on)
  = note: first definition in `core` loaded from /home/joshua/.local/lib/cargo/target/debug/deps/libcore-afaeeb022194dcf3.rmeta
  = note: second 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

error[E0119]: conflicting implementations of trait `ffi::c_str::CString::new::SpecIntoVec` for type `&str`:
   --> library/std/src/ffi/c_str.rs:392:9
    |
379 |         impl<T: Into<Vec<u8>>> SpecIntoVec for T {
    |         ---------------------------------------- first implementation here
...
392 |         impl SpecIntoVec for &'_ str {
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `&str`
    |
    = note: upstream crates may add a new impl of trait `core::convert::Into<alloc_crate::vec::Vec<u8>>` for type `&str` in future versions

error: aborting due to 119 previous errors; 93 warnings emitted
```

Now, they're much more helpful:

```
$ cargo check
   Compiling core v0.0.0 (/home/joshua/rustc2/library/core)
error: failed to run custom build command for `core v0.0.0 (/home/joshua/rustc2/library/core)`

Caused by:
  process didn't exit successfully: `/home/joshua/.local/lib/cargo/target/debug/build/core-ea3b18d34c1ee1c8/build-script-build` (exit code: 101)
  --- stderr
  error: you are attempting to build libcore without going through bootstrap
  help: use `x.py build --stage 0 library/std`, not `cargo build`
  help: use `x.py check`, not `cargo check`
  note: if you're sure you want to do this, use `RUSTC_BOOTSTRAP=0` or some other dummy value
  thread 'main' panicked at 'explicit panic', library/core/build.rs:7:9
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

The metric here is 'did you set RUSTC_BOOTSTRAP'; if so, it's assumed
you know what you're doing and no error is given. It's very unlikely (or
at least should be!) that someone will have RUSTC_BOOTSTRAP globally
set, so I think this is a good heuristic.
@bjorn3
Copy link
Member

bjorn3 commented Sep 7, 2020

This will break xargo and cargo-xbuild.

@jyn514
Copy link
Member Author

jyn514 commented Sep 7, 2020

This will break xargo and cargo-xbuild.

I don't know how those work. Do they build with nightly, is that how they allow using nightly features? Is there a way to tell the difference between cargo build and cargo xbuild? Is it feasible to ask them to set RUSTC_BOOTSTRAP=0?

@bjorn3
Copy link
Member

bjorn3 commented Sep 7, 2020

Do they build with nightly, is that how they allow using nightly features?

Yes

Is it feasible to ask them to set RUSTC_BOOTSTRAP=0?

I think so. Xargo is in maintenance mode, but it is still used by miri.

@Mark-Simulacrum
Copy link
Member

Hm instead of repurposing RUSTC_BOOTSTRAP for this, could we add a new variable?

FWIW this does just work with "cargo check --manifest-path library/test/Cargo.toml" so maybe we should be suggesting that. build also works, though test currently does not.

@jyn514
Copy link
Member Author

jyn514 commented Sep 7, 2020

FWIW this does just work with "cargo check --manifest-path library/test/Cargo.toml" so maybe we should be suggesting that.

How hard would it be to have cargo do that automatically? Maybe by putting that file in library/Cargo.toml and making it a workspace? cc @joshtriplett

@Mark-Simulacrum
Copy link
Member

I suspect having two workspaces in rust-lang/rust might be a good idea long-term regardless to lessen various other pains, so I wouldn't mind having a dedicated library workspace. That'll take some work, though.

@Mark-Simulacrum Mark-Simulacrum added S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 13, 2020
@jyn514 jyn514 added the A-contributor-roadblock Area: Makes things more difficult for new contributors to rust itself label Sep 20, 2020
@camelid
Copy link
Member

camelid commented Oct 16, 2020

What is this blocked on?

@jyn514
Copy link
Member Author

jyn514 commented Oct 16, 2020

This is blocked on either convincing xargo, cargo-xbuild, and cargo -Z build-std to unconditionally pass RUSTC_BOOTSTRAP, or finding some other way to do this that doesn't require setting environment variables.

@jyn514
Copy link
Member Author

jyn514 commented Oct 16, 2020

finding some other way to do this that doesn't require setting environment variables

Ideally, we could just make cargo build delegate to cargo build -p library/test, but that requires cargo support that doesn't yet exist.

@Mark-Simulacrum
Copy link
Member

I'm going to go ahead and close this as I think the things it is blocked on are unlikely to change in the near future -- the general problem is one we'd like to solve, but I doubt it'll happen quickly...

@jyn514 jyn514 deleted the cargo-build branch December 29, 2020 18:13
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Jan 30, 2024
…haelwoerister

Improve error message when `cargo build` is used to build the compiler

Inspired by rust-lang#76446.

Doing it for `core` is probably higher value but also way harder because tools like cargo or rustc-build-sysroot would need to be fixed first, which I don't feel like doing.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jan 30, 2024
Rollup merge of rust-lang#120475 - Nilstrieb:cargo-build-my-a-, r=michaelwoerister

Improve error message when `cargo build` is used to build the compiler

Inspired by rust-lang#76446.

Doing it for `core` is probably higher value but also way harder because tools like cargo or rustc-build-sysroot would need to be fixed first, which I don't feel like doing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-contributor-roadblock Area: Makes things more difficult for new contributors to rust itself S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Give a better error message when running cargo test on libstd itself
5 participants