diff options
| author | bors <bors@rust-lang.org> | 2025-05-08 02:16:45 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2025-05-08 02:16:45 +0000 |
| commit | 7e552b46af72df390ed233b58a7f51650515b2a8 (patch) | |
| tree | f8aec230f54c32fdc51d778a9856fc753a6ceb1a /compiler/rustc_pattern_analysis/src/errors.rs | |
| parent | ae3e8c6191fb2bf9394ea4201adaf7b1ac496120 (diff) | |
| parent | 09fed2d2f440fff2179ca9373bb16e40fc81d935 (diff) | |
| download | rust-7e552b46af72df390ed233b58a7f51650515b2a8.tar.gz rust-7e552b46af72df390ed233b58a7f51650515b2a8.zip | |
Auto merge of #140106 - dianne:deref-pat-usefulness, r=Nadrieril
allow deref patterns to participate in exhaustiveness analysis Per [this proposal](https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Exhaustiveness), this PR allows deref patterns to participate in exhaustiveness analysis. Currently all deref patterns enforce `DerefPure` bounds on their scrutinees, so this assumes all patterns it's analyzing are well-behaved. This also doesn't support [mixed exhaustiveness](https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Mixed-exhaustiveness), and instead emits an error if deref patterns are used together with normal constructors. I think mixed exhaustiveness would be nice to have (especially if we eventually want to support arbitrary `Deref` impls[^1]), but it'd require more work to get reasonable diagnostics[^2]. Tracking issue for deref patterns: #87121 r? `@Nadrieril` [^1]: Regardless of whether we support limited exhaustiveness checking for untrusted `Deref` or always require other arms to be exhaustive, I think it'd be useful to allow mixed matching for user-defined smart pointers. And it'd be strange if it worked there but not for `Cow`. [^2]: I think listing out witnesses of non-exhaustiveness can be confusing when they're not necessarily disjoint, and when you only need to cover some of them, so we'd probably want special formatting and/or explanatory subdiagnostics. And if it's implemented similarly to unions, we'd probably also want some way of merging witnesses; the way witnesses for unions can appear duplicated is pretty unfortunate. I'm not sure yet how the diagnostics should look, especially for deeply nested patterns.
Diffstat (limited to 'compiler/rustc_pattern_analysis/src/errors.rs')
| -rw-r--r-- | compiler/rustc_pattern_analysis/src/errors.rs | 14 |
1 files changed, 13 insertions, 1 deletions
diff --git a/compiler/rustc_pattern_analysis/src/errors.rs b/compiler/rustc_pattern_analysis/src/errors.rs index e60930d6cd2..156ba973767 100644 --- a/compiler/rustc_pattern_analysis/src/errors.rs +++ b/compiler/rustc_pattern_analysis/src/errors.rs @@ -1,5 +1,5 @@ use rustc_errors::{Diag, EmissionGuarantee, Subdiagnostic}; -use rustc_macros::{LintDiagnostic, Subdiagnostic}; +use rustc_macros::{Diagnostic, LintDiagnostic, Subdiagnostic}; use rustc_middle::ty::Ty; use rustc_span::Span; @@ -133,3 +133,15 @@ pub(crate) struct NonExhaustiveOmittedPatternLintOnArm { pub lint_level: &'static str, pub lint_name: &'static str, } + +#[derive(Diagnostic)] +#[diag(pattern_analysis_mixed_deref_pattern_constructors)] +pub(crate) struct MixedDerefPatternConstructors<'tcx> { + #[primary_span] + pub spans: Vec<Span>, + pub smart_pointer_ty: Ty<'tcx>, + #[label(pattern_analysis_deref_pattern_label)] + pub deref_pattern_label: Span, + #[label(pattern_analysis_normal_constructor_label)] + pub normal_constructor_label: Span, +} |
