"can't find crate" errors are easy to miss because they result in many more follow-up errors

[jplatte]

Given a crate that depends on bytes 1.1.0, trying to cargo build --target target_that_is_not_installed results in

error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-unknown-redox` target may not be installed
  = help: consider downloading the target with `rustup target add x86_64-unknown-redox`

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

error[E0463]: can't find crate for `alloc`
  --> /home/jplatte/.cargo/registry/src/github.com-1ecc6299db9ec823/bytes-1.1.0/src/lib.rs:78:1
   |
78 | extern crate alloc;
   | ^^^^^^^^^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for `std`
  --> /home/jplatte/.cargo/registry/src/github.com-1ecc6299db9ec823/bytes-1.1.0/src/lib.rs:81:1
   |
81 | extern crate std;
   | ^^^^^^^^^^^^^^^^^ can't find crate
   |
   = note: the `x86_64-unknown-redox` target may not be installed
   = help: consider downloading the target with `rustup target add x86_64-unknown-redox`

error[E0463]: can't find crate for `core`
 --> /home/jplatte/.cargo/registry/src/github.com-1ecc6299db9ec823/bytes-1.1.0/src/buf/buf_impl.rs:5:5
  |
5 | use core::{cmp, mem, ptr};
  |     ^^^^ can't find crate
  |
  = note: the `x86_64-unknown-redox` target may not be installed
  = help: consider downloading the target with `rustup target add x86_64-unknown-redox`

followed by a few more can't find crate for `core` errors, followed by around 500 additional errors about individual items from the standard library not being found. The first of these appear very fast, so it's inconvenient (and sometimes impossible due to scrollback limitations) to actually find the relevant errors at the start.

I think at least one of two things should happen here:

• Failing to find a critical crate like core or std should abort compilation immediately
• If an external crate (or a module?) can't be resolved, don't report errors about symbols not being found that were meant to be imported from there

[LoganDark]

I think this can be generalized a bit because I often find myself wanting to fix errors in the order they are reported rather than in reverse. It would be nice if rustc/cargo supported some sort of "max errors" / "max diagnostics" flag that would stop compilation after that point (or just silence further errors/diagnostics). That way I could work through them one by one without having to constantly use the scrollback.

My shell prompt is only 1 line, so when trying to reach the beginning of a super long sequence of errors, it's super easy to miss the initial invocation of cargo and accidentally cross over into the previous compilation's output. I end up using tricks like pressing newline a bunch of times before running cargo so it's easier for me to spot the boundary.

[estebank]

I'm somewhat surprised because I thought we were already silencing resolution errors for paths starting with identifiers that have already emitted a failure, but it seems like our handling of extern crate foo isn't as comprehensive as I'd thought.

If an external crate (or a module?) can't be resolved, don't report errors about symbols not being found that were meant to be imported from there

It should be relatively straightforward to do this: we already do it for some imports. We "just" need to extend the behavior for chained uses.

Failing to find a critical crate like core or std should abort compilation immediately

That's what we used to do back in 2017. I'm opposed to going back, that is a blunt tool that doesn't serve users as well as it might seem at first.

It would be nice if rustc/cargo supported some sort of "max errors" / "max diagnostics" flag that would stop compilation after that point

In nightly, you can (ab)use --Ztreat-err-as-bug=N for that.

or just silence further errors/diagnostics

That's what we already do: pretty much every internal representation of code has an Err variant so that knock down errors are silenced, only for the cases where it is relevant, while also letting the compiler emit errors of elsewhere in the codebase. If we didn't do this, the experience of "waves of errors"/"I fixed the last error and then I got 200 more" would be way more common.

[jyn514]

cc #96799

[fasterthanlime]

that is a blunt tool that doesn't serve users as well as it might seem at first.

Can you expand on that @estebank ? I want to believe there's a rationale for the current behavior, but I can't for the life of me figure it out.

I don't see what happy ending there can be if the target is not installed — to me that remains the 1st big papercut everyone encounters when they try targeting wasm32-unknown-unknown.

[estebank]

I want to believe there's a rationale for the current behavior, but I can't for the life of me figure it out.

@fasterthanlime the desire is to remove all cases of early stops in the compiler because otherwise it's easy to add more and more over time, accidentally or not. Having said that, today I wouldn't be against making this a hard error. The current behavior isn't putting the user first either.

[kevincox]

I can see the benefit of removing early stops but it seems that it must not come at the expensive of false-positive errors. False errors just waste the users time as they need to triage them to identify where the actual error is. IMHO it would need to be a very conservative ruling out of anything that the compiler isn't sure about. In this case since the crate was note found the compiler should not report anything else related to that crate as it doesn't know if those are actually issues.

Basically the compiler should assume that the crate is perfect, and not report any error that could potentially be resolved by the crate. Any function referenced should be assumed to be present and any unknown method calls should be assumed to be a trait in that crate.