Cargo check doesn't catch error in associated constant

[rjsberry]

Problem

Attempting to compile a basic Rust program with errors fails to build with cargo build (as expected), however running cargo check on the same program exits without error.

This happens either with panic!/assert! or overflow/underflow errors in associated constants. It does not fail with constant items.

Steps

Run cargo build and cargo check on the following minimum example:

struct Assert;

impl Assert {
    const ASSERT: () = panic!();
}

#[allow(path_statements)]
fn main() {
    Assert::ASSERT;
}

Running cargo build:

% cargo b
   Compiling cargo-check-mre v0.1.0 (~/Code/cargo-check-mre)
error[E0080]: evaluation of constant value failed
 --> src/main.rs:4:24
  |
4 |     const ASSERT: () = panic!();
  |                        ^^^^^^^^ the evaluated program panicked at 'explicit panic', src/main.rs:4:24
  |
  = note: this error originates in the macro `$crate::panic::panic_2021` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)

note: erroneous constant used
 --> src/main.rs:9:5
  |
9 |     Assert::ASSERT;
  |     ^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0080`.
error: could not compile `cargo-check-mre` due to previous error

Running cargo check:

% cargo check
    Checking cargo-check-mre v0.1.0 (~/Code/cargo-check-mre)
    Finished dev [unoptimized + debuginfo] target(s) in 0.39s

Possible Solution(s)

No response

Notes

Attempting to run the same checks on a program with errors in a constant item works as expected:

const _: () = panic!();

fn main() {}

Both cargo build and cargo check fail.

Version

cargo 1.67.1 (8ecd4f20a 2023-01-10)
release: 1.67.1
commit-hash: 8ecd4f20a9efb626975ac18a016d480dc7183d9b
commit-date: 2023-01-10
host: aarch64-apple-darwin
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.85.0 (sys:0.4.59+curl-7.86.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 13.1.0 [64-bit]

[ehuss]

Thanks for the report! This is a known issue where I believe const propagation does not happen in a check build because it is a slow and expensive process.

I'm going to close as a duplicate of rust-lang/rust#70923 (I think). There has been work very recently to investigate this, though it is a difficult problem, since this and other stages could slow down a check build considerably (rust-lang/lang-team#195).