-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add note on non-exhaustiveness when matching on str and nested non-exhaustive enums #115270
Conversation
Some changes might have occurred in exhaustiveness checking cc @Nadrieril |
@@ -18,6 +19,7 @@ LL | match "world" { | |||
| ^^^^^^^ pattern `&_` not covered | |||
| | |||
= note: the matched value is of type `&str` | |||
= note: `str` cannot be matched exhaustively, so a wildcard `_` is necessary |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of adding an additional note, I wonder if it's easier to just specialize the help message "ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown" below to be a bit more context specific, explaining something a bit more directly about how strings aren't exhaustive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean something like the following?
help: as `str` cannot be matched exhaustively, ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
I think it would make the help message too lengthy. My understanding is that notes can be used to provide further explanation or context on what caused the error instead of cluttering the help message with too much context.
But I don't have a strong opinion on this, so I'll be happy to make the change if needed. If we do make the change, do you think it would be necessary to make the change for pointer-sized ints as well for consistency??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also prefer we didn't add a note, but I don't know how we'd phrase it. The tricky thing is that the non exhaustive type may be deep in a pattern somewhere (e.g. Result<Option<&str>, ...>
), which prevents us from saying e.g. "ensure all possible strings are being handled".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh oops forgot about this one before merging. I think it's ok like this, if one of you has a better idea we can make another PR. My secret plan is to suggest actual missing strings, something like patterns Some(""), Some("a"), Some("b") and many others not covered
but I expect that will take some work.
Thanks again @sebastiantoh! The logic looks sound. r=me once the phrasing nitpicks have been addressed |
Thanks for the review! I've addressed the phrasing comments @bors r=Nadrieril |
hm maybe you need rights to do this @bors r+ |
…eril Add note on non-exhaustiveness when matching on str and nested non-exhaustive enums Fixes rust-lang#105479 r? `@Nadrieril`
☀️ Test successful - checks-actions |
Finished benchmarking commit (21305f4): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 629.273s -> 630.367s (0.17%) |
seems like continued spurious noise on bitmaps-3.1.0 @rustbot label: +perf-regression-triaged |
Fixes #105479
r? @Nadrieril