Repository navigation
Moving AsciiExt methods to types is a footgun for maintaining backwards compatibility #46510
Description
In Rust 1.22.1, this code compiles:
use std::ascii::AsciiExt;
fn main() {
"a".eq_ignore_ascii_case("a");
}In Rust 1.23.0.beta.1, it issues a warning:
warning: unused import: `std::ascii::AsciiExt`
--> src/main.rs:1:5
|
1 | use std::ascii::AsciiExt;
| ^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(unused_imports)] on by default
My tidiness kicks in and I remove the trait — no one wants warnings, right?
However, if I remove this trait, my crates will no longer compile on older versions of Rust. I've actually been bitten by this twice now, and one of those times has been released to crates.io. 😞
Activity
shepmaster commentedon Dec 5, 2017
/cc @LukasKalbertodt @SimonSapin @sfackler (key people on #44042)
shepmaster commentedon Dec 5, 2017
At least one project pointed to the PR as an issue as well (rusoto/rusoto#877).
shepmaster commentedon Dec 5, 2017
For now, I'm going to do:
Mark-Simulacrum commentedon Dec 5, 2017
I believe this has been discussed and the
allow(unused)solution is our recommendation; I don't think that's awful, though I agree it's not great.SimonSapin commentedon Dec 5, 2017
This was discussed in https://users.rust-lang.org/t/psa-dealing-with-warning-unused-import-std-ascii-asciiext-in-today-s-nightly/13726, but yeah it’s not great. Maybe a different error message would help?
shepmaster commentedon Dec 5, 2017
If this has already been discussed to death, then I'm OK with closing this issue as you see fit.
Perhaps, although special-casing such a thing in the beta cycle seems rough.
We could potentially also post a cut-down version of the warning and the suggestion into the release notes?
SimonSapin commentedon Dec 5, 2017
I wouldn’t say "to death".
Release notes sounds good.
Also, if this is judged bad enough, there’s always the option to revert this change in 1.23 beta to give us time to have better diagnostics in 1.24. I don’t have a strong opinion on this.
alexcrichton commentedon Dec 5, 2017
We discussed this during the libs triage meeting today and we agreed this is definitely unfortunate! For warnings like deprecation we typically avoid actually deprecating until the alternative hits stable (for this precise reason) but in this scenario it's a little different because we can't implement the change here without having warnings!
We agreed that we'll close this for now though. In general we want to head off these sorts of situations and prevent them from happening (and we do) but this is a particularly special case which seems pretty unlikely to come up again and not necessarily worth the trouble of more compiler changes.
For now though yeah the recommended solution/workaround would be
#[allow(unused)]sfackler commentedon Dec 5, 2017
The only remaining contexts this could come up IIRC are the target-specific extension traits. We need to implement the platform compatibility lint before that can happen though, so those are quite a ways off. It might be worth revisiting a smarter lint then since we'll already be digging around in that infrastructure.