Skip to content
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

Don't use exact definition of std's ErrorKind in test. #7406

Merged
merged 1 commit into from
Jul 1, 2021

Conversation

m-ou-se
Copy link
Member

@m-ou-se m-ou-se commented Jun 26, 2021

Every time we add something to std::io::ErrorKind, this clippy test breaks. This is especially annoying because it usually only happens when bors is testing it (e.g. in a rollup), as clippy tests are normally not run for PRs with just library changes.

For example: rust-lang/rust#85746 (comment)

This changes the test to not rely on the definition from std.


Please write a short comment explaining your change (or "none" for internal only changes)

changelog: none

Every time we add something to this enum in std, this test breaks.
@rust-highfive
Copy link

r? @flip1995

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Jun 26, 2021
Copy link
Member

@flip1995 flip1995 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, except Cam's comment. I also don't think we need that many variants and/or try to match std. 2 or 3 should be enough.

@flip1995 flip1995 added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Jun 28, 2021
bors added a commit that referenced this pull request Jul 1, 2021
Don't suggest doc(hidden) or unstable variants in wildcard lint

Clippy's wildcard lint would suggest doc(hidden) and unstable variants for non_exhaustive enums, even though those aren't part of the public interface (yet) and should only be matched on using a `_`, just like potential future additions to the enum. There was already some logic to exclude a *single* doc(hidden) variant. This extends that to all hidden variants, and also hides `#[unstable]` variants.

See rust-lang/rust#85746 (comment)

This PR includes #7406 as the first commit.

Here's the diff that this PR adds on top of that PR: m-ou-se/fork@std-errorkind...m-ou-se:doc-hidden-variants

---

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog:
 - No longer suggest unstable and doc(hidden) variants in wildcard lint.
bors added a commit that referenced this pull request Jul 1, 2021
Don't suggest doc(hidden) or unstable variants in wildcard lint

Clippy's wildcard lint would suggest doc(hidden) and unstable variants for non_exhaustive enums, even though those aren't part of the public interface (yet) and should only be matched on using a `_`, just like potential future additions to the enum. There was already some logic to exclude a *single* doc(hidden) variant. This extends that to all hidden variants, and also hides `#[unstable]` variants.

See rust-lang/rust#85746 (comment)

This PR includes #7406 as the first commit.

Here's the diff that this PR adds on top of that PR: m-ou-se/fork@std-errorkind...m-ou-se:doc-hidden-variants

---

*Please write a short comment explaining your change (or "none" for internal only changes)*

changelog: No longer suggest unstable and doc(hidden) variants in wildcard lint. wildcard_enum_match_arm, match_wildcard_for_single_variants
@bors bors merged commit 3e59563 into rust-lang:master Jul 1, 2021
@m-ou-se m-ou-se deleted the std-errorkind branch July 2, 2021 18:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants