What are the divergence rules around const eval?

[ehuss]

#2067 added a chapter on divergence, but we noted some uncertain behavior around const expressions. I had some specific questions that hopefully have clear answers:

• Can a const expression have type !?
• Can a const expression diverge?
• Does the divergence of a const expression propagate to its outer block?
• Are there any differences between different kinds of const expressions (like a static/const items, const contexts, const {} blocks)?
• How does this relate to async blocks? Do they have similar behavior?

For this purpose, I think we can ignore uninhabited-static which looks like it was not intended.

We struggled a little with examples because there is different behavior between cargo check and cargo build. We were initially assuming that if it passed cargo check it was also passing typechecking, but there might be something more complex going on there.

cc @jackh726

---

Jack said:

What I'm seeing is actually that const blocks (along with async blocks) is that they do not propagate their divergence because they essentially act as independent function bodies. Of course, divergence can exist inside:

fn f() {
    const {
        panic!();
        let _x = 0;
    }
}

and also:

my best guess is that const eval is just masking typecheck here: we need to figure out the type of the const block, but can never do that because const eval doesn't complete.

---

Example 1: diverging const block

Considering the following:

fn trailing_const_panic() -> ! {
    const { panic!() } // OK, seems const block has ! type
}
fn non_trailing_statement_const_panic() -> ! {
    const { panic!() };
    // ERROR, expected `!`, found `()`
}

I was confused on this (the semicolon). Jack says:

This has a pretty simple explanation: the former results in an expected type of ! for the const block so the type of the const block is ! - the latter has no expectation because of the semicolon, so the type of the block ! fallbacks to ().

but I don't understand that. My base assumption was that a const {} block would have the same rules and behavior as a normal block. And indeed, if you remove the const from non_trailing_statement_const_panic, it successfully compiles. Why would its type fall back to () if it is const?

Example 2: Read from a place

@traviscross came up with a variation that includes a read from a place, and the semicolon is moved inside the const {} block:

fn read_from_place_with_semicolon() -> ! {
    let _x = (const {
        panic!();
    },).0;
}

fn read_from_place_without_semicolon() -> ! { //~ ERROR: Mismatched types.
    let _x = (const {
        panic!()   // No semicolon
    },).0;
}