Code change:
cc Code first. This code: , gives this set of error messages: The part that I'm most concerned about is: Before eRFC "if- and while-let-chains, take 2" (rust-lang/rfcs, , ), this code USED to result in this error message: The reason I know this is because , in the section where we're trying to explain the difference between statements and expressions. The error message I'm seeing now is muddying the waters by saying " expressions". Based on my reading of the eRFC, it's only supposed to change , but as kind of a side effect is now sort-of an expression? The don't clear it up for me, as they only describe , not plain s. What I expected is that even though the eRFC has been accepted and implemented, plain would still be considered a statement and the error message wouldn't talk about " expressions". If my expectation is valid, then the compiler error message is a bug. If my expectation is invalid, please let me know so that I can work on updating the book. Thanks! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also notes in  if sync discussion is desired. So the new compiler error, introduced in , here is by design and tested in which has more notes. Specifically, the error here comes from HIR lowering. The idea is that is a syntactically valid expression in all cases (on nightly). The distinction between semantic and syntactic can be noticed via macros and conditional compilation. Semantically however, is only allowed in the cases that notes, namely the cases generated by the grammar : Eventually however, e.g. with a follow-up RFC, I would like to turn into a true semantic expression typed at such that e.g. becomes legal. So overall the goal is to "muddy the waters". The reference has not been updated because we only make updates to it once a feature becomes stable. With all that said, I'm open to tweaks to the error message (it's optimized for suggesting that e.g. is not legal). For example, we could have a different note for stable compilers or when the feature gate is not active. cc
I would be happy with a different error message for stable compilers that continued to call outside of a statement rather than an expression.
Should be easy to implement by tweaking the HIR lowering code just a tiny bit. Will try to do that sometime during the week but no firm promises. :)
if anyone wants to work-steal this from me then this would be a good first issue. You'll want to tweak  by keeping the current wording when holds and changing it to suggested wording (the old one) otherwise.
There's precedent for different messages depending on whether the current compiler is stable or not and whether there's a feature flag enabled or not. I don't think all three cases are needed here and just gate on the feature being enabled.
I'd go further to say that we should be doing what describes most of the time: unless a feature is enabled, and the old diagnostics were useful, don't spit out new "you tried to use this feature but it's unstable" diagnostics that aren't helpful.
I'll take a stab at it. First time contributor, so I might not know all the hurtles, but I'll take a swing at it.
assign
I'm not sure if this is a good idea, because is usually used to create variable bindings. But with expressions, the scope of these variables can get much more complicated. Example:
It's probably best to discuss that once an RFC is made but let's not do it here. :)
claim
I've got the change locally now with exactly what had mentioned in a previous message. The only thing I'm getting right now is that the compiler is highlighting the entire statement and not just the keyword like before. I'm looking for the method where I can get this. I'll put up a PR in a bit to show where I'm at along with some terminal output to demonstrate a bit better what I'm talking about if it doesn't make sense already.
Opened
Don't worry about the span, it is ok as it is in your pr.

Related discussion:
text: /// ``` fn lower_expr_let(&mut self, span: Span, pat: &Pat, scrutinee: &Expr) -> hir::ExprKind { // If we got here, the `let` expression is not allowed. <del> self.sess .struct_span_err(span, "`let` expressions are not supported here") .note("only supported directly in conditions of `if`- and `while`-expressions") .note("as well as when nested within `&&` and parenthesis in those conditions") .emit(); </del> <ins> if self.sess.opts.unstable_features.is_nightly_build() { self.sess .struct_span_err(span, "`let` expressions are not supported here") .note("only supported directly in conditions of `if`- and `while`-expressions") .note("as well as when nested within `&&` and parenthesis in those conditions") .emit(); } else { self.sess .struct_span_err(span, "expected expression, found statement (`let`)") .note("variable declaration using `let` is a statement") .emit(); } </ins> // For better recovery, we emit: // ```