missing-const-for-fn: println is not const-(st)able yet

[matthiaskrgr]

Summary

fn a() {
    let x = 1 else { return }; //~ WARN irrefutable `let...else` pattern

    // Multiline else blocks should not get printed
    let x = 1 else { //~ WARN irrefutable `let...else` pattern
        eprintln!("problem case encountered");
        return
    };
}

this cannot be a const fn yet although clippy suggets it:

error[E0015]: cannot call non-const fn `std::io::_eprint` in constant functions
 --> a.rs:6:9
  |
6 |         eprintln!("problem case encountered");
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants
  = note: this error originates in the macro `eprintln` (in Nightly builds, run with -Z macro-backtrace for more info)

error: `std::fmt::Arguments::<'a>::new_const` is not yet stable as a const fn
 --> a.rs:6:9
  |
6 |         eprintln!("problem case encountered");
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: add `#![feature(const_fmt_arguments_new)]` to the crate attributes to enable
  = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `eprintln` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 2 previous errors; 4 warnings emitted

Lint Name

missing-const-for-fn:

Reproducer

I tried this code:

<code>

I saw this happen:

<output>

I expected to see this happen:

Version

rustc 1.81.0-nightly (9c3bc805d 2024-06-27)
binary: rustc
commit-hash: 9c3bc805dd9cb84019c124b9a50fdff1e62a7ec9
commit-date: 2024-06-27
host: x86_64-unknown-linux-gnu
release: 1.81.0-nightly
LLVM version: 18.1.7

Additional Labels

No response

[y21]

ouch, looks like optimized_mir, which is the only MIR-query that clippy can use afaik, does not have the else block in the MIR at all (probably as an optimization since it's always unreachable due to an infallible pattern?), so it doesn't see the eprintln!.

We are setting mir-opt-level to 0 in the driver specifically I think to prevent issues like this but it seems like even that's not enough... Actually, I think this is basically the same issue as #6080, but provides a real example where this breaks code

[DaniPopes]

I've investigated this a bit further.

The MIR in this case looks like:

    bb0: {
        _9 = const 1_i32;
        falseEdge -> [real: bb3, imaginary: bb4];
    }

where bb4 is the unreachable else part of the let-else.

This gets transformed by CleanupPostBorrowck:

    bb0: {
        _9 = const 1_i32;
        goto -> bb3;
    }

... removing the reference to bb4, which means the block will get cleaned up by any of the passes that call simplify_cfg or remove_dead_blocks.

I've experimented with disabling these passes to try to keep the unreachable blocks in the body, but this causes failures elsewhere (like could not find BorrowIndex for location bb108[8]).

Even if we had access to mir_drops_elaborated_and_const_checked/mir_for_ctfe, this would still happen because the simplification passes are ran as part of analysis/lowering.