Remove `unwrap` from `match_trait_method` by m-rph · Pull Request #12540 · rust-...
source link: https://github.com/rust-lang/rust-clippy/pull/12540
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Remove unwrap
from match_trait_method
#12540
Merged
Conversation
Unused_IO_amount relies on match_trait_method
in order to match trait methods that exist in Tokio traits as the corresponding symbols don't exist.
With this commit we remove the unwrap that caused #12366.
Note: author (@m-rph) and @GuillaumeGomez couldn't replicate #12366.
changelog:none
r? @blyxyas
added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label
I don't think this is enough to close #12366, I'd like to make sure there isn't some bad assumption in the lint implementation. This (unused_io) is the only lint that relies on |
Removing this function if it doesn't do what's expected of it seems like the way forward indeed. As for the change, looks good to me. 👍 |
Removing it most likely requires adding a diag symbols for tokio (is that even possible?). Maybe there's an alternative? |
Member
If it's deprecated with only one use remaining it could be moved out of clippy utils |
Should I move it to
|
Member
Ah it's documented as a fallback. Could leave it, I don't feel too strongly either way |
Contributor
This doesn't need to change. #12366 is a rustc issue since lints shouldn't have been running after an error. |
Contributor
Author
As is it can still fail, but I don't feel particularly strongly about this. |
LGTM, thanks! ❤️
I'm not sure if this is what caused the original issue, or even if it should be handled within Clippy (it seems to be an issue in the compiler), but I'll still merge this because an unwrap
less in the codebase is still a win!
"Better that then false positives, than that ICE propagates."
William Blackstone.
Member
If it's already documented in the book as a fallback, I would keep it, just another option for contributors. Also, adding a diagnostic item for tokio (or any external crate) would not be a wise decision. Philipp talked against it for future lints (we have some lints based on futures I think, and those were a mistake), so yeah :/ @bors r+ |
Collaborator
💔 Test failed - checks-action_test |
Member
Changelog failure. |
Collaborator
💡 This pull request was already approved, no need to approve it again.
|
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
No milestone
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK