PSA: Dealing with “warning: unused import: `std::ascii::AsciiExt`” in today’s Nightly

announcements
1

If your code uses the std::ascii::AsciiExt trait and you upgrade your compiler to today’s Nightly, you might see a warning like this:

warning: unused import: `std::ascii::AsciiExt`
  --> /home/simon/servo3/components/script/dom/bindings/str.rs:10:5
   |
10 | use std::ascii::AsciiExt;
   |     ^^^^^^^^^^^^^^^^^^^^
   |
   = note: #[warn(unused_imports)] on by default

This is because https://github.com/rust-lang/rust/pull/44042 has just landed, making some of this trait’s methods available as inherent methods. The inherent ones take priority in method resolution, so the trait is now unused.

If you only need to support one compiler version you can just remove the use line. But if you also want to compile without warnings on both the Stable and Nightly channels (say if you maintain a library) the trick for now is to silence the warning just for that line:

#[allow(unused_imports)] use std::ascii::AsciiExt;

(Edit: unused_imports plural, not unused_import.)

The #[…] syntax instead of #![…] makes this attribute apply only to the following item, not the entire module.

After the new inherent methods reach the stable channel we’ll deprecate the AsciiExt trait in Nigthly and you’ll get new warnings. At that point it should be safe to remove these imports entirely.

11 Likes
2

Removing the imports entirely would still constitute a breaking change as far as semver is concerned, so please remember to bump your versions appropriately if you want to go that route or silence them and keep the import to keep backwards compatibility

3

Oh, do you mean because it increases the minimum Rust version? Personally I’m undecided about whether that should be considered breaking. In practice it seems that few libraries actually track and test a minimum version.

4

I think it's a huge ecosystem problem because it requires people to track stable. This is very easy to do for developers with the tools they use, it's very hard for software projects that actually want their code used across a large ecosystem. My background is the Tor project, most of our (relay) users (those who actually make up the network) are on Debian stable, but we also have users on rhel, various BSDs, etc. Toolchain updates are a major pain because some distribution somewhere always doesn't yet have the shiny new tools. I really think Rust developers are taking the easy way out if they declare that Rust itself isn't subject to the same semver guarantees that it encourages everyone else to adhere to. Chasing stable Rust compiler updates is in no way a sustainable model for us and tracking down failures happening because libraries don't declare their breaking changes correctly is really annoying.

I think crates should declare a minimum compiler version they work with, and when that changes that's an automatic semver bump.

8 Likes
5

I strongly agree (also, declaring at least one nightly version they work with if the crate is nightly only). With Travis CI it's also super easy, just a single line specifying the minimum version and you get all the same tests you're running on stable running on that version as well.

1 Like
6

There are some discussion in whether bumping minimum compiler version constitutes as a breaking change: https://github.com/rust-lang-nursery/api-guidelines/issues/123

1 Like
7

Every single crate I work on tracks a minimum Rust version, and thus far, I've been issuing semver bumps whenever I increase the minimum Rust version required.

(I remain undecided as to whether this is what everyone should be doing...)

2 Likes
8

I was inspired by this thread to finally write down my thoughts: https://github.com/rust-lang-nursery/api-guidelines/issues/123#issuecomment-342470263

1 Like