Add a chapter on divergence

[jackh726]

It was little tricky when trying to describe diverging blocks. The compiler's implementation maintains sort of a "global state" when checking an expression and sub-expressions, which it resets on conditional things. Semantically, I think the way I worded it is much clearer than trying to match the implementation.

Happy to hear any specific feedback, Lcnr made did an initial review pass in rust-lang/project-goal-reference-expansion@4079171, so the second commit tries to address that.

[traviscross]

Thanks for the PR @jackh726; I can tell this was written carefully. It will be good to get more of this documented. In particular, it'll be good to have the fallback behavior documented.

I'll leave some notes inline. Probably we'll want to move some things around.

Adding more examples -- even beyond what I'll note specifically inline -- would be particularly good for this material. It's helpful when each rule has one or more concise and testable examples demonstrating exactly what the rule means to express.

[traviscross]

We try to keep the number of top-level chapters contained. Looking at it, perhaps most of what's here that can't be inlined on the pages for each expression would make sense appearing in the Expressions chapter (e.g., we talk about place and value expressions there -- the verbiage about when a place expression is diverging might make sense near that) and in the Never type chapter.

[traviscross]

If we're inlining the rule about determining the type based on the LUB for match, from https://doc.rust-lang.org/1.90.0/reference/type-coercions.html#r-coerce.least-upper-bound.intro, probably we'd need to do that for the other rules there also (and then either remove the list from there or convert it to an admonition or index).

[traviscross]

As an aside, looking into this rule is what prompted me to file:

• Test of least upper bound coercion behavior triggers ICE rust#148283

[jackh726]

Thanks for the review @traviscross. Good points here, I'll work on sorting through them today/tomorrow.

Happy to jump on a call at some point too, if you think any of these could use further discussion.

[traviscross]

This compiles and produces an infinite loop.

Playground link

But then, so does:

    let foo = Foo { x: make() };
    let diverging_place_not_read: () = {
        let _: () = {
            // Asssignment to something other than `_` means?
            let _x = foo.x;
        };
    };

Playground link

Is there a way to demonstrate this such that let _ = .. produces distinct compile-time or runtime behavior from let _x = ..?

[traviscross]

To answer the question posed, this compiles:

trait RetId { type Ty; }
impl<T> RetId for fn() -> T { type Ty = T; }

struct S<T> {
    x: T,
}

fn f(x: S<<fn() -> ! as RetId>::Ty>) -> ! {
    let _x = x.x; // OK.
}

But this does not:

fn f(x: S<<fn() -> ! as RetId>::Ty>) -> ! {
    let _ = x.x; // ERROR: Mismatched types.
}

This is one, though, where it's not immediately coming to mind how to express this without either the never type or the never type hack.

[traviscross]

Here's one way. (Of course, this is really just another instantiation of the never type hack.)

fn phantom_call<T>(_: impl FnOnce(T) -> T) {}

let _ = phantom_call(|x| -> ! {
    let _x = x; // OK.
});
let _ = phantom_call(|x| -> ! {
    let _ = x; // ERROR: Mismatched types.
});

[traviscross]

It's interesting how it really does need the ! type to be ascribed for this to work. I.e., it doesn't work with:

struct W<T>(T);

let x = W(loop {});
let _ = || -> ! {
    let _x = x.0; // ERROR.
};

Any thoughts about the reason for that?

[jackh726]

It's interesting how it really does need the ! type to be ascribed for this to work. I.e., it doesn't work with:

struct W<T>(T);

let x = W(loop {});
let _ = || -> ! {
    let _x = x.0; // ERROR.
};

Any thoughts about the reason for that?

This one nearly stumped me, because I had my mind set that this was a closure thing. But then I realized, this also fails:

let _: ! = {
    let _x = x.0;
};

The important bit to remember here is that x.0 is an inference var which does not produce divergence (only place expressions that produce types of ! do). The "expectation" value of the block (either as the block's type, or the closure's return value) does not constrain that inference variable.

[traviscross]

Makes sense, thanks. (And yes, the only purpose of the closure in the examples is to be able to ascribe the type without nightly features.)

Coincidentally, prompted by lcnr apropos of lcnr's work, I was just looking at something else today with a similar flavor:

trait Tr: Sized {
    fn abs(self) -> i32 { 0 }
}
impl Tr for i32 {}

fn main() {
    let x = -42;
    let y: i32 = x.abs();
    assert!(y != x.abs()); // Surprising, but true.
}

[traviscross]

@rustbot author

[rustbot]

Error: shortcut handler unexpectedly failed in this comment: failed to remove Label { name: "S-waiting-on-review" }

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

[yaahc]

does this require a diverging scrutinee expression to compile?

probably worth adding an example either way

[jackh726]

This is a good question! The answer is (subtly) no. Take the following:

fn make<T>() -> T { loop {} }
enum Empty {}

fn diverging_match_no_arms() -> ! {
    let e: Empty = make();
    match e {}
}

e is uninhabited, but is not considered diverging from a type-checking standpoint. To make it more confusing, this also fires the unreachable_code lint, like diverging expressions, but not in the same code path

Adding this as an example.

[yaahc]

lgtm, I was wondering if there would be a good place to link to the glossary item on uninhabited types as related but distinct but I couldn't find a good place. Wanted to mention the idea in case you can think of a way to fit it in and you think its valuable to do so.

[nikomatsakis]

Some drive-by comments.

[nikomatsakis]

Does "this entire block" refer to the block of the fn body? I found it a touch ambiguous.

[nikomatsakis]

I would rather say:

"Divergence is the state where a particular section of code will never terminate" -- although it too is approximate.

"If an expression diverges, then nothing after that expression will execute"

something like that I guess.