This allows deref patterns to move out of boxes.
Implementation-wise, I've opted to put the information of whether a
deref pattern uses a built-in deref or a method call in the THIR. It'd
be a bit less code to check `.is_box()` everywhere, but I think this way
feels more robust (and we don't have a `mutability` field in the THIR
that we ignore when the smart pointer's a box). I'm not sure about the
naming (or using `ByRef`), though.
Since deref patterns on boxes will be lowered differently, I'll be
making a separate test file for them. This makes sure we're still
testing the generic `Deref(Mut)::deref(_mut)`-based lowering.
Implicit deref patterns allow previously ill-typed programs. Make sure
they're still ill-typed without the feature gate. I've thrown in a test
for `deref!(_)` too, though it seems it refers to `deref_patterns` as a
library feature.
The place previously used here was that of the temporary holding the
reference returned by `Deref::deref` or `DerefMut::deref_mut`. However,
since the inner pattern of `deref!(inner)` expects the deref-target type
itself, this would ICE when that type was inspected (e.g. by the EUV
case for slice patterns). This adds a deref projection to fix that.
Since current in-tree consumers of EUV (upvar inference and clippy)
don't care about Rvalues, the place could be simplified to
`self.cat_rvalue(pat.hir_id, self.pat_ty_adjusted(subpat)?)` to save
some cycles. I personally find EUV to be a bit fragile, so I've opted
for pedantic correctness. Maybe a `HACK` comment would suffice though?
This handles using deref patterns to choose the correct match arm. This
does not handle bindings or guards.
Co-authored-by: Deadbeef <ent3rm4n@gmail.com>
