What are the divergence rules around const eval?

Inizia dal capitolo sulla divergenza aggiunto da Rust Reference pull request 2067, quindi riproduci gli esempi di const-block e confronta cargo check con cargo build. Analizza le domande elencate su const expressions, divergence propagation e i semicolon cases. Il lavoro è completato quando le regole sono state chiarite e documentate nella Reference con esempi chiari.

https://github.com/rust-lang/reference/pull/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?
• If it is possible to 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)?

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;
}