rust-lang / rust-lang/reference
What are the divergence rules around const eval?
Nobody has claimed this yet.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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