-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
suggest use of the match_default_bindings feature gate #45383
Copy link
Copy link
Closed
Labels
C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.E-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.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.WG-diagnosticsWorking group: DiagnosticsWorking group: Diagnostics
Metadata
Metadata
Assignees
Labels
C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.E-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.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.WG-diagnosticsWorking group: DiagnosticsWorking group: Diagnostics
Type
Fields
Give feedbackNo fields configured for issues without a type.
Right now, if the
match_default_bindingsis not enabled, then type check does not even attempt to auto-deref on pattern match. This makes it rather undiscoverable. If I try to run this program, for example:I get:
Of course, if I add the feature gate, it works.
What I would like is for some kind of hint that the feature gate is available, at least on nightly builds. As an example, if I use slice patterns (also unstable) on nightly, I get:
(On stable, the help is not present.) This error results from this code here which invokes the
gate_features_post!macro. I'm not 100% sure what error message we should use here, but I think we should do something similar.Roughly speaking, the idea would be this:
tcx.sess.features.borrow().match_default_bindingsfrom this line and instead enter theifthe same either way.feature_errfunction to create an error to emit.&-pattern here".The final error would thus look something like:
This error is...a bit funky. We might want to play with the wording. Maybe it wants to be something like:
We could then make an extended error message for E0123 that explains the RFC a bit too.
cc @tschottdorf @estebank