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

Unstable lints in v0.30.1 #760

Closed
daniestevez opened this issue Nov 10, 2023 · 5 comments · Fixed by #762
Closed

Unstable lints in v0.30.1 #760

daniestevez opened this issue Nov 10, 2023 · 5 comments · Fixed by #762

Comments

@daniestevez
Copy link

svd2rust v0.30.1 is including

# ! [deny (private_bounds)]
# ! [deny (private_interfaces)]

in the generated output when running as svd2rust --target none -i my_registers.svd -o src/

These lints are unstable and the resulting code gives warnings when built with rustc 1.73.0:

warning: unknown lint: `private_bounds`
  --> src/lib.rs:11:1
   |
11 | # ! [deny (private_bounds)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: the `private_bounds` lint is unstable
   = note: see issue #48054 <https://github.com/rust-lang/rust/issues/48054> for more information
   = note: `#[warn(unknown_lints)]` on by default

warning: unknown lint: `private_interfaces`
  --> src/lib.rs:12:1
   |
12 | # ! [deny (private_interfaces)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: the `private_interfaces` lint is unstable
   = note: see issue #48054 <https://github.com/rust-lang/rust/issues/48054> for more information

svd2rust v0.30.0 doesn't do this. I've seen that this change was in included in f097443, apparently to fix the clippy lints on nightly, but it seems that it breaks them on stable.

@Emilgardis
Copy link
Member

I think we should add #[allow(unknown_lints)] to circumvent this, but also possibly #[allow(renamed_and_removed_lints)] (I'm less sure about this one, since hiding these would mean it's harder to catch.)

@jessebraham
Copy link
Member

I think we should add #[allow(unknown_lints)] to circumvent this, but also possibly #[allow(renamed_and_removed_lints)] (I'm less sure about this one, since hiding these would mean it's harder to catch.)

I was going to suggest the former option, as well.

@ianrrees
Copy link

I wonder if it would make sense to have the CI checks set RUSTFLAGS="-D warnings" so that compile warnings cause the check to fail?

@burrbull
Copy link
Member

@ianrrees
Copy link

Thanks @burrbull ! Two takeaways:

  1. The warnings in question go away with Rust 1.74.0 which recently stabilized.
  2. Per discussion around RFC 3389, which added the lints table to Cargo.toml (in particular this comment), it doesn't seem like the lints table currently provides a way to make cargo error out if warnings are encountered. Add option to error when warnings are emitted, or ignore warnings rust-lang/cargo#12875 would add a cargo command line option to do that though.

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 a pull request may close this issue.

5 participants