Diagnostics in MIR passes (arithmetic_overflow, unconditional_panic) are not caught with cargo check

[ishitatsuyuki]

I just tried to ran the compile-fail suite without trans, and these tests failed:

failures:
    [compile-fail] compile-fail/array_const_index-0.rs
    [compile-fail] compile-fail/array_const_index-1.rs
    [compile-fail] compile-fail/asm-src-loc.rs
    [compile-fail] compile-fail/bad-intrinsic-monomorphization.rs
    [compile-fail] compile-fail/cdylib-deps-must-be-static.rs
    [compile-fail] compile-fail/const-err-early.rs
    [compile-fail] compile-fail/const-err-multi.rs
    [compile-fail] compile-fail/const-err.rs
    [compile-fail] compile-fail/const-err2.rs
    [compile-fail] compile-fail/const-err3.rs
    [compile-fail] compile-fail/const-eval-overflow2.rs
    [compile-fail] compile-fail/const-eval-overflow2b.rs
    [compile-fail] compile-fail/const-eval-overflow2c.rs
    [compile-fail] compile-fail/const-slice-oob.rs
    [compile-fail] compile-fail/dupe-symbols-1.rs
    [compile-fail] compile-fail/dupe-symbols-2.rs
    [compile-fail] compile-fail/dupe-symbols-3.rs
    [compile-fail] compile-fail/dupe-symbols-4.rs
    [compile-fail] compile-fail/dupe-symbols-5.rs
    [compile-fail] compile-fail/dupe-symbols-6.rs
    [compile-fail] compile-fail/dupe-symbols-7.rs
    [compile-fail] compile-fail/huge-array.rs
    [compile-fail] compile-fail/huge-enum.rs
    [compile-fail] compile-fail/huge-struct.rs
    [compile-fail] compile-fail/impl-trait/infinite-impl-trait-issue-38064.rs
    [compile-fail] compile-fail/infinite-instantiation.rs
    [compile-fail] compile-fail/issue-10755.rs
    [compile-fail] compile-fail/issue-11154.rs
    [compile-fail] compile-fail/issue-15919.rs
    [compile-fail] compile-fail/issue-17913.rs
    [compile-fail] compile-fail/issue-22638.rs
    [compile-fail] compile-fail/issue-26548.rs
    [compile-fail] compile-fail/issue-44578.rs
    [compile-fail] compile-fail/issue-8460-const.rs
    [compile-fail] compile-fail/issue-8727.rs
    [compile-fail] compile-fail/linkage2.rs
    [compile-fail] compile-fail/linkage3.rs
    [compile-fail] compile-fail/lint-exceeding-bitshifts.rs
    [compile-fail] compile-fail/lint-exceeding-bitshifts2.rs
    [compile-fail] compile-fail/nolink-with-link-args.rs
    [compile-fail] compile-fail/non-interger-atomic.rs
    [compile-fail] compile-fail/panic-runtime/abort-link-to-unwind-dylib.rs
    [compile-fail] compile-fail/panic-runtime/libtest-unwinds.rs
    [compile-fail] compile-fail/panic-runtime/transitive-link-a-bunch.rs
    [compile-fail] compile-fail/panic-runtime/two-panic-runtimes.rs
    [compile-fail] compile-fail/panic-runtime/want-abort-got-unwind.rs
    [compile-fail] compile-fail/panic-runtime/want-abort-got-unwind2.rs
    [compile-fail] compile-fail/panic-runtime/want-unwind-got-abort.rs
    [compile-fail] compile-fail/panic-runtime/want-unwind-got-abort2.rs
    [compile-fail] compile-fail/recursion.rs
    [compile-fail] compile-fail/required-lang-item.rs
    [compile-fail] compile-fail/rmeta_lib.rs
    [compile-fail] compile-fail/simd-intrinsic-generic-arithmetic.rs
    [compile-fail] compile-fail/simd-intrinsic-generic-cast.rs
    [compile-fail] compile-fail/simd-intrinsic-generic-comparison.rs
    [compile-fail] compile-fail/simd-intrinsic-generic-elements.rs
    [compile-fail] compile-fail/simd-intrinsic-generic-reduction.rs
    [compile-fail] compile-fail/simd-type-generic-monomorphisation.rs
    [compile-fail] compile-fail/symbol-names/basic.rs
    [compile-fail] compile-fail/symbol-names/impl1.rs
    [compile-fail] compile-fail/type_length_limit.rs

All of those happens somewhere inside librustc_mir, most of them being monomorphization. This corresponds to translation item collection pass, which takes nontrivial amount of time.

Though, we should to try to evaluate things like struct layout, symbols even when we're doing check to catch all kind of errors.

[gnzlbg]

Some / all of the simd failures would need to move typeck from librustc_typeck to MIR typeck to avoid monomorphization time errors. This is something that should be done anyways and AFAICT there is no tracking issue for it.

[RalfJung]

Here's a current example of this:

fn main() {
    let _val = 14u8 + 255;
}

The "overflow" diagnostic does not trigger with --emit=metadata.

I think the fix here would be to move this somewhere that is actually run during check:

rust/compiler/rustc_mir_transform/src/lib.rs

Line 496 in 795ade0

&Lint(const_prop_lint::ConstProp),

I'm a bit surprised that doesn't already happen... I assume we do call mir_drops_elaborated_and_const_checked since that's where mir_borrowck is called, but then from there we should be calling run_analysis_to_runtime_passes which calls run_runtime_lowering_passes which runs the const_prop_link pass. I guess I am not understanding the control flow of our MIR pass manager -- as usual, that thing has always been messy.^^

[RalfJung]

It would probably make sense to distinguish between "just produce the rmeta file as fast as possible" (check on dependencies) and "check the current crate (but fast)". It makes little sense to run the MIR lint passes on dependencies when lints are hidden anyway... but on the current crate I am working on I'd probably like to see these lints.

[RalfJung]

Besides const_prop_lint, another pass that can emit errors is lower_intrinsics.

@rust-lang/wg-mir-opt if you know any other MIR passes that can emit errors or lints, please post them here. Also in the interest of keeping the differences between check and build as small as possible, it'd be good to avoid adding more such passes. :)

[oli-obk]

We can move the lower_intrinsics diagnostics to mir typeck.