Are those Reference parts completely wrong/outdated?

[WiktorPrzetacznik]

1. Path patterns (src):

Qualified path patterns can only refer to associated constants

How about this? -> <Enum>::A
Couldn't this be used as a qualified path pattern, for example in match arms?

---

2. Trait bounds (src):

Bounds that don't use the item's parameters or higher-ranked lifetimes are checked when the item is defined. It is an error for such a bound to be false

This below is not checked on definition:

// Compiles on its own
//             vvvvvvv higher-ranked trait bound (HRTB)
fn foo() where for<'a> String: Copy {}

fn main() {
    // error to call it (this is where the HRTB is checked)
    foo();
}

And this is checked on definition:

struct A<'a, T>
where
    i32: Iterator,          // Error: `i32` is not an iterator
{
    f: &'a T,
}

fn main() {
}

So it looks like bounds that don't use the item's parameters are checked on definition, but higher-ranked lifetimes are not.

---

3. Temporary scopes (src):

Apart from lifetime extension, the temporary scope of an expression is the smallest scope that contains the expression and is one of the following:
(...)

• The second operand of a lazy boolean expression.

It looks like LHS is a temporary scope, too.
Playground example provided by @CAD97 from rust.internals

(forum discussion)

[ehuss]

For the qualified path patterns, that is indeed not updated, and is tracked in #631.

For the HRTB validation, that looks like a bug in rustc to me. It looks like it changed in rust-lang/rust#84682. I can't offhand think of a HRTB that would inherently be false, so I'm not sure what the original text was referring to.

For the lazy boolean drop scope, it looks like that changed in rust-lang/rust#103293 but the reference was never updated.

[WiktorPrzetacznik]

Can the reference part of qualified path patterns be quickfixed or rather it should be done as a part of whole "type_alias_enum_variants documentation" (as stated in #631)? I'm asking because I'm planning to propose some reference fixes and improvements in near future and I may include it.

[ehuss]

It's fine to make incremental progress. Just keep in mind that it is very helpful to point to the reasoning why something changed (like an RFC, stabilization report, or a PR description), and bonus points if you can point to the compiler tests that exhibit the change and the location in the compiler where the relevant behavior is implemented.