-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Downgrade unnested_or_patterns to pedantic #5705
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
r? @flip1995 (rust_highfive has picked a reviewer for you, use r? to override) |
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 think the original idea was to stabilize or-patterns rather quickly and auto-apply the lint to the rustc codebase afterwards, but there has not been much progress lately rust-lang/rust#54883
@bors r+ |
📌 Commit 56f25e3 has been approved by |
Downgrade unnested_or_patterns to pedantic Even with #5704 fixed, I don't believe it is a safe bet that if someone is using or-patterns anywhere in a codebase then they want to use it as much as possible in the whole codebase. I think it would be reasonable to reevaluate after the feature is stable. I feel that a warn-by-default lint suggesting use of an unstable feature, even if already being used in one place, is questionable. changelog: Remove unnested_or_patterns from default set of enabled lints
💔 Test failed - checks-action_test |
Let's see if that's spurious, can't reproduce locally. |
Downgrade unnested_or_patterns to pedantic Even with #5704 fixed, I don't believe it is a safe bet that if someone is using or-patterns anywhere in a codebase then they want to use it as much as possible in the whole codebase. I think it would be reasonable to reevaluate after the feature is stable. I feel that a warn-by-default lint suggesting use of an unstable feature, even if already being used in one place, is questionable. changelog: Remove unnested_or_patterns from default set of enabled lints
💔 Test failed - checks-action_test |
It seems the ICE only happens when using master-bootstrapped clippy:
|
There's already an upstream ticket ❤️ rust-lang/rust#73249 |
A fix is in progress: rust-lang/rust#73257 |
@bors rollup |
Rollup of 9 pull requests Successful merges: - #5178 (clippy-driver: pass all args to rustc if --rustc is present) - #5705 (Downgrade unnested_or_patterns to pedantic) - #5709 (Fix ICE in consts::binop) - #5710 (typo) - #5712 (Remove `bar` from blacklisted names) - #5713 (Use lints in Clippy that are enabled in rustc bootstrap) - #5716 (Fix typo in wildcard_imports) - #5724 (redundant_pattern_matching: avoid non-`const fn` calls in const contexts) - #5726 (Fix typo) Failed merges: r? @ghost changelog: rollup
Even with #5704 fixed, I don't believe it is a safe bet that if someone is using or-patterns anywhere in a codebase then they want to use it as much as possible in the whole codebase. I think it would be reasonable to reevaluate after the feature is stable. I feel that a warn-by-default lint suggesting use of an unstable feature, even if already being used in one place, is questionable.
changelog: Remove unnested_or_patterns from default set of enabled lints