[WIP] implement explicit deref patterns through k#deref

[fee1-dead]

Some technical considerations: (feel free to add to the list)

1. The first commits in this PR are based on Treat k#ident keywords as valid tokens #119351, adding support for the k#ident syntax.
2. Variants added: ast::PatKind::Deref, hir::PatKind::Deref, thir::PatKind::DerefPattern, mir::TestKind::Deref.
3. We use Deref for now, but we might want a different trait (DerefPure) later.
4. In typeck, we deref the expected (input type of the expression) type exactly once for simplicity, and then type check the inner pattern with <expected as Deref>::Target. Doing multiple derefs with a single k#deref isn't supported for now, and we might want to explore how to do implicit/multiple derefs later.
5. The actual codegen first takes the place being matched (let us call that place), creates a temporary references &place, then calls deref. (place2 = Deref::deref(&place)). The inner patterns then use (*place2) for continued matching. This means: (TODO: add test for types that cannot be moved out)

match vec![1] {
    k#deref [x] => {} // `x` here has type `i32`, not `&i32`
}

6. We skip generating false edges from or to arms with deref patterns. This behavior should be fixed before this PR actually get merged, since it means that any unreachable arm under deref patterns would not be borrowcked. (see the vec-2.rs test for this) Clarification: skipping false edges are done because deref patterns generate temporaries that are used to create bindings. When false edges are generated for deref patterns the temporaries don't get assigned to since they are assigned to during the tests and not before an arm block starts, which lead to borrowck errors.
7. The key to the matching algorithm is in sort_candidate, where we replace the original match pair of PatKind::DerefPattern with the inner pattern on the new temporary created by the deref. Note that since sort_candidate can be called on multiple candidates after a test is performed, we need to ensure that the peeling of deref pattern on a match pair only happens once (through is_first), so that the subsequent match arms all do their derefs individually and get tested individually.
8. The current impl only does Deref as being deliberately minimal. We would want to figure out the binding mode and try doing the appropriate deref in the future.
9. There is no guarantee that only a single deref occurs. In fact, point 7, through is_first is opposed to this idea. We'd probably want to explore whether is_first is really necessary with more testing.

cc @compiler-errors @BoxyUwU @Nadrieril @matthewjasper @tgross35 @CAD97 (would like to hear from you about the implementation)

[rustbot]

r? @petrochenkov

(rustbot has picked a reviewer for you, use r? to override)

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

    Checking same-file v1.0.6
    Checking crossbeam-channel v0.5.8
    Checking term v0.7.0
    Checking color-eyre v0.6.2
error[E0004]: non-exhaustive patterns: `rustc_hir::PatKind::Deref(_)` not covered
    --> src/tools/clippy/clippy_utils/src/hir_utils.rs:959:15
959  |         match pat.kind {
959  |         match pat.kind {
     |               ^^^^^^^^ pattern `rustc_hir::PatKind::Deref(_)` not covered
note: `rustc_hir::PatKind<'_>` defined here
    --> /checkout/compiler/rustc_hir/src/hir.rs:1152:1
     |
     |
1152 | pub enum PatKind<'hir> {
...
...
1193 |     Deref(&'hir Pat<'hir>),
     = note: the matched value is of type `rustc_hir::PatKind<'_>`
     = note: the matched value is of type `rustc_hir::PatKind<'_>`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
     |
1020 ~             PatKind::Never | PatKind::Wild => {},
1021 ~             rustc_hir::PatKind::Deref(_) => todo!(),

    Checking rustc_version v0.4.0
    Checking getopts v0.2.21
    Checking comma v1.0.0
    Checking comma v1.0.0
    Checking bytes v1.4.0
    Checking levenshtein v1.0.5
    Checking ui_test v0.21.2
    Checking tester v0.9.1
error[E0004]: non-exhaustive patterns: `rustc_hir::PatKind::Deref(_)` not covered
     |
1708 |     match pat.kind {
1708 |     match pat.kind {
     |           ^^^^^^^^ pattern `rustc_hir::PatKind::Deref(_)` not covered
note: `rustc_hir::PatKind<'_>` defined here
    --> /checkout/compiler/rustc_hir/src/hir.rs:1152:1
     |
     |
1152 | pub enum PatKind<'hir> {
...
...
1193 |     Deref(&'hir Pat<'hir>),
     = note: the matched value is of type `rustc_hir::PatKind<'_>`
     = note: the matched value is of type `rustc_hir::PatKind<'_>`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
1735 ~         },
1735 ~         },
1736 ~         rustc_hir::PatKind::Deref(_) => todo!(),

For more information about this error, try `rustc --explain E0004`.
error: could not compile `clippy_utils` (lib) due to 2 previous errors
warning: build failed, waiting for other jobs to finish...

[petrochenkov]

r? compiler
I'm overloaded with reviews.

[petrochenkov]

Also, k#ident is an even worse hack than r#ident.
If context-sensitive keywords don't work in this position, use something like do yeet or builtin #.

[fee1-dead]

re k#ident: I will change this soon.

For point number 6, Nadrieril suggested that we do the Deref more than once: one when we do the test, to allow subsequent tests to match on the deref temporary, and do it again when pre-binding, for the false edges to work correctly. This would be unsound if we used Deref, which is a safe trait, but would not be an issue once we switch to using DerefPure.

[WaffleLapkin]

@petrochenkov I don't think I agree. k# and r# are basically identical. Moreover k#something is oftentimes used as a placeholder by T-lang when designing stuff, so it's not taken from nowhere (I think they even wanted to use it for actual feature prototypes, although we never went along with it so far...).

I think it should be totally fine as a placeholder here and can't really see any issues...

[bors]

☔ The latest upstream changes (presumably #119578) made this pull request unmergeable. Please resolve the merge conflicts.

[fee1-dead]

closing in favor of #122222.