Decide whether to suggest anything when encountering break and expecting !

[estebank]

#63337 (comment) introduces suggestions when encountering break without a value in a context that expects a value other than (). In the case that the expected value is ! we don't suggest anything. Once ! is stabilized, we should look at the actual usage and see if there's any sane situation where we would like to suggest something like break loop {}.

CC @Centril

[johnfercher]

Hi, I would like to work in this issue. Could you explain the context of the modification?

[estebank]

Hi @johnfercher! Thank you for wanting to contribute. At this point we first need to evaluate whether suggesting anything in this case is useful or detrimental to newcomers. The actual implementation part is straightforward and I can help you with it, but first we need to confirm we want to add such a suggestion to the compiler. Does that make sense?

[johnfercher]

Hi, @estebank totally make sense. How we proceed to confirm this?

[estebank]

@Centril who should be involved in this conversation?

[Centril]

I'm not sure, but let's wait until ! has been stable for a bit tho, yea?

[justjosias]

It's been a year. Should this be looked at again?

[hameerabbasi]

Another year. :) Maybe E-easy should be removed, so new contributors like me don't stumble on it?

[pnkfelix]

Discussed in T-compiler backlog bonanza.

Its not clear what concrete piece of code/scenario this issue is talking about.

As best I can tell, it is describing a scenario like this:

fn diverge() -> ! {
    loop {
        break 3;
    }
}

and the diagnostic needs to suggest something to put in for the input expression to break, and someone at some point suggested this:

fn diverge() -> ! {
    loop {
        break loop { };
    }
}

If that's what's being discussed, I definitely do not think the above suggestion is good. I don't know what the right suggestion is (it could be "do not break", or it could be "replace the break with an inner loop { }, or panic, etc.)

Anyway, we do not understand the exact scenario that was under discussion in the first place; the above is largely guesswork.

---

Furthermore, this isn't really a tracking issue; it isn't tracking progress on a language/compiler feature. Its just a note about a potential gotcha in the code.

@rustbot label: -C-tracking-issue

[estebank]

Let's just close. I've lost the context of what I was thinking back then, and I feel like it might be ok to ignore the issue for now until we have an actionable report with a realistic case.