allow deref patterns to move out of boxes by dianne · Pull Request #140022 · rust-lang/rust (original) (raw)

Rollup merge of rust-lang#140028 - dianne:lit-deref-pats-p1, r=oli-obk

deref_patterns: support string and byte string literals in explicit deref!("...") patterns

When deref_patterns is enabled, this allows string literal patterns to be used where str is expected and byte string literal patterns to be used where [u8] or [u8; N] is expected. This lets them be used in explicit deref!("...") patterns to match on String, Box<str>, Vec<u8>, Box<[u8;N]>, etc. (as well as to match on slices and arrays obtained through other means). Implementation-wise, this follows up on rust-lang#138992: similar to how byte string literals matching on &[u8] is implemented, this changes the type of the patterns as determined by HIR typeck, which informs const-to-pat on how to translate them to THIR (though strings needed a bit of extra work since we need references to call <str as PartialEq>::eq in the MIR lowering for string equality tests).

This PR does not add support for implicit deref pattern syntax (e.g. "..." matching on String, as string_deref_patterns allows). I have that implemented locally, but I'm saving it for a follow-up PR[^1].

This also does not add support for using named or associated constants of type &str where str is expected (nor likewise with named byte string constants). It'd be possible to add that if there's an appetite for it, but I figure it's simplest to start with literals.

This is gated by the deref_patterns feature since it's motivated by deref patterns. That said, its impact reaches outside of deref patterns; it may warrant a separate experiment and feature gate, particularly factoring in the follow-up[^1]. Even without deref patterns, I think there's probably motivation for these changes.

The update to the unstable book added by this will conflict with rust-lang#140022, so they shouldn't be merged at the same time.

Tracking issue for deref patterns: rust-lang#87121

r? @oli-obk cc @Nadrieril

[^1]: The piece missing from this PR to support implicit deref pattern syntax is to allow string literal patterns to implicitly dereference their scrutinees before matching (see rust-lang#44849). As a consequence, it also makes examples like the one in that issue work (though it's still gated by deref_patterns). I can provide more information on how I've implemented it or open a draft if it'd help in reviewing this PR.