Repository navigation
Wrong diagnostic when using constant of TAIT type in pattern #102011
Description
Activity
- addedWG-diagnosticsWorking group: DiagnosticsWorking group: DiagnosticsF-type_alias_impl_trait`#[feature(type_alias_impl_trait)]``#[feature(type_alias_impl_trait)]`
on Sep 19, 2022 - moved this to Can do after stabilization in type alias impl trait stabilization
on Sep 19, 2022 i do think we should experiment with adding the too generic type to
TooGeneric, i tried splitting that variant which was more annoying than helpful- addedC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lints
on Sep 20, 2022 inquisitivecrystal commented
on Sep 20, 2022 ContributorMore actionsTriage note: I was going to add one or more of the
D-labels, but wasn't sure which ones were appropriate. The OP and linked post don't really help me to understand what's going on and why it's a problem. I'm sure they're perfectly comprehensible to those who understand the situation better than I do, but a little bit of elaboration might help make this issue clearer. :)Oof, yea, sorry about that. I added some explanation including what should actually be done.
Reacted by inquisitivecrystal- addedE-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
on Sep 20, 2022 - addedD-incorrectDiagnostics: A diagnostic that is giving misleading or incorrect information.Diagnostics: A diagnostic that is giving misleading or incorrect information.C-bugCategory: This is a bug.Category: This is a bug.and removedC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.
on Sep 20, 2022 my idea was
pub enum ErrorHandled<'tcx> { Reported(ErrorGuaranteed), Linted, TooGeneric(Ty<'tcx>), }
Ty<'tcx>might not be perfect, e.g. sometimes we fail to resolve an instance, so there usingTy<'tcx>is wrong 🤔 maybeTooGeneric(&'tcx TooGenericCause<'tcx>)withTooGenericCause<'tcx>being an enum with the variants we care about 🤔this should give us pretty good error messages with a hopefully acceptable perf impact
Reacted by Oli SchererThis no longer reports the same error as the issue, and instead just says:
error: `Bar` cannot be used in patterns --> src/main.rs:15:9 | 15 | LEAK_FREE => (), | ^^^^^^^^^ warning: unreachable pattern --> src/main.rs:16:9 | 15 | LEAK_FREE => (), | --------- matches any value 16 | _ => (), | ^ unreachable pattern | = note: `#[warn(unreachable_patterns)]` on by default warning: `playground` (bin "playground") generated 1 warning error: could not compile `playground` due to previous error; 1 warning emitted- addedE-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.Call for participation: An issue has been fixed and does not reproduce, but no test has been added.and removedE-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
on Oct 22, 2022 Triage: Since we already have a test as
src/test/ui/type-alias-impl-trait/structural-match-no-leak.rs, I think we could just close this issue. Closing.- moved this from Can do after stabilization to Done in type alias impl trait stabilization
on Jan 5, 2023
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
The test src/test/ui/type-alias-impl-trait/structural-match-no-leak.rs (copied below to preserve its state)
reports an error about "depends on a generic parameter", when there are no generic parameters anywhere. The issue is that we only have a single
TooGenericvariant in https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/enum.ErrorHandled.html#variant.TooGeneric . We should change that fieldless variant toTooGeneric(TooGeneric)and introduce anOriginally posted by @lcnr in #101478 (comment)