Add information about || and && to grammar describing while let.

[steffahn]

Also fix italics to be consistent with other pages.
See #771. I also copied and adapted the corresponding paragraph from the if let page.
Edit: Instead of copying the paragraph from if let mentioning the unstable if-let chains feature, now the copy as well as the original paragraph are removed.

[Centril]

This is user advice and discussion of unstable features, which is off-topic for the reference.

[steffahn]

Then perhaps it should also be removed from the page about if expressions?

[Centril]

Probably yes, cc @ehuss

[ehuss]

I think it's fine to keep this information, though place it in a "note" block. I don't see a reason to never talk about such things, since it is relevant here (explaining a strange peculiarity of the language). The C++ reference does the same with side notes mentioning future changes or how to disambiguate things that aren't obvious.

The information only needs to live in one place. if let would be fine, with while let linking to if let for more information. I might even trim while let even more to remove redundant information, but doesn't necessarily need to be done in this PR.

[Centril]

Putting it in a note and deduplicating seems like a reasonable resolution to me.

[steffahn]

@ehuss I'm questioning if "Expression_except struct or lazy boolean operator expression" is even accurate. It seems like the compiler is currently, internally, for parsing and some typechecking, treating

let PAT = EXPR

just like an expression of type bool with precedence between && and ==. Hence not only lazy boolean operators but also binary and postfix .. and ..= don't work in if let expression without parantheses.

[ehuss]

Hm, I don't have the answer for that, @Centril should. It looks like let has special precedence rules (parse_let_expr) from if let (parse_assoc_expr). I'm not too familiar with how that works.

I general, the reference is missing lots of information on precedence rules and disambiguations, so don't be too surprised about details like this not being covered (though they should!).

[Centril]

@ehuss I'm questioning if "Expression__except struct or lazy boolean operator expression_" is even accurate. It seems like the compiler is currently, internally, for parsing and some typechecking, treating

This only applies to parsing and AST level validation. Type checking (done on HIR) does not care about parenthesis and precedences. The old note is probably outdated by now.

Hm, I don't have the answer for that, @Centril should. It looks like let has special precedence rules (parse_let_expr) from if let (parse_assoc_expr). I'm not too familiar with how that works.

Yes, the parser treats let pat = scrutinee as an expression on its own, and specifically requires that scrutinee has a minimum precedence of one above the precedence of &&. The relevant code is:

/// In `let p = e`, operators with precedence `<=` this one requires parenthesis in `e`.
pub fn prec_let_scrutinee_needs_par() -> usize {
    AssocOp::LAnd.precedence()
}

    /// Parses a `let $pat = $expr` pseudo-expression.
    fn parse_let_expr(&mut self, attrs: AttrVec) -> PResult<'a, P<Expr>> {
        let pat = self.parse_top_pat(GateOr::No)?;
        self.expect(&token::Eq)?;
        let expr = self.with_res(Restrictions::NO_STRUCT_LITERAL, |this| {
            this.parse_assoc_expr_with(1 + prec_let_scrutinee_needs_par(), None.into())
        })?;

...so what we should do is document the minimum precedence requirement; everything else just falls out automatically. (We shouldn't document that let is an expression on its own, as that is still an unstable implementation detail.)

[Centril]

Let's merge this but also follow up re. the precedence issue.