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

rustc: remove deprecated private_in_public lint #2886

Closed
wants to merge 1 commit into from

Conversation

kaffarell
Copy link
Contributor

@kaffarell kaffarell commented Feb 19, 2024

The private_in_public rustc lint is now deprecated and throws a warning on each cargo check. According to the rfc 1 this lint is being substituted by three other ones: private_interfaces, private_bounds and unnameable_types.
unnameable_types is not yet stabilized 2, so it will throw a warning, but we will be ready when it is :)

Footnotes

  1. https://rust-lang.github.io/rfcs/2145-type-privacy.html

  2. https://github.com/rust-lang/rust/pull/120144

The `private_in_public` rustc lint is now deprecated and throws a
warning on each `cargo check`. According to the rfc [0] this lint is
being substituted by three other ones: `private_interfaces`,
`private_bounds` and `unnameable_types`.
`unnameable_types` is not yet stabilized [1], so it will throw a warning,
but we will be ready when it is :)

[0]: https://rust-lang.github.io/rfcs/2145-type-privacy.html
[1]: rust-lang/rust#120144
@mladedav
Copy link
Contributor

We could add #![allow(unknown_lints)] for the time being so that there are no warnings now and we can keep the lint that is yet to be stabilised.

Ideally with a TODO comment to get rid of it once the last lint is stabilized.

@kaffarell
Copy link
Contributor Author

We could... but I am not sure—this could lead to us forgetting about it :/
@hawkw what do you think?

@hawkw
Copy link
Member

hawkw commented Mar 1, 2024

This has already been fixed on master in #2814, so I've backported that commit to v0.1.x. Thanks!

Regarding adding #[allow(unknown_lints)], I think it would be a good idea to change our CI builds to pass --allow unknown_lints when running lint checks (e.g., here:

args: --all --examples --tests --benches -- -D warnings
). That way, contributors still get warnings from local runs of cargo check/cargo clippy when adding attributes referencing lists that don't exist as part of a change, but CI won't fail when a lint is removed/deprecated. That seems like a good compromise between not breaking CI on new Rust versions and warning contributors that a lint isn't valid. What do you think?

@hawkw hawkw closed this Mar 1, 2024
@kaffarell
Copy link
Contributor Author

Yes, I agree!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants