rust-lang / rust-lang/reference

What are the divergence rules around const eval?

Open
#2,153 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

A-const-eval A-divergence
Dominant language
Rust
Stars
1.6k
Forks
607
PR merge metrics
PR metrics pending

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the divergence chapter added by Rust Reference pull request 2067, then reproduce the const-block examples and compare cargo check with cargo build. Investigate the listed questions for const expressions, divergence propagation, and the semicolon cases. Done means the rules are resolved and documented in the Reference with clear examples.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.