Closed oherrala closed 5 years ago
Likely caused by https://github.com/rust-lang/rust/pull/59825, but considered acceptable breakage.
This breaks some crates that compiled before, e.g. dipstick
and lettre_email
. Just curious, why is this considered acceptable in this case?
These cases can be made to work again by locally elaborating types or the used impl (eg. using <Type as Trait>::method(...)
syntax), so the fallout is easy to fix.
Specifically, since this is essentially inference breakage it is permitted per our policies. If there is some reason this causes significant difficulty for you, though, we'd like to hear about that and may reconsider.
@Mark-Simulacrum Thanks for your response. This doesn't cause any problem at all for me – I was just curious about what kind of breakage is permitted and what isn't. I found the commitments in this blog post as well.
I hit this problem today when trying to update to the latest nightly release when one of my dependencies (rustyline) depended on this behavior. Because of this I'm unable to update because I don't control the dependency.
Edit: Looks like rustyline has already fixed this issue upstream. Sorry for the noise :)
This libs team discussed this yesterday and agreed this falls within our policy. If anyone has any difficulty upgrading though or working through this, please let us know and we can try to help out.
Triaging crater, this caused a number of regressions. Code-ified most of the detailed regression lists below to avoid pinging lots of folks who are not the root cause of the regression; I'm reopening this due to the extent of the ecosystem damage here and re-nominating.
root: rustyline - 73 detected crates which regressed due to this; cc @kkawakam, @gwenn
root: ucg - 2 detected crates which regressed due to this; cc @zaphar
root: wee-rl - 1 detected crates which regressed due to this; cc @jblondin
root: tcalc-rustyline - 1 detected crates which regressed due to this; cc @dubrowgn
root: amethyst_assets - 6 detected crates which regressed due to this; cc @Xaeroxe, @torkleyy, @Rhuagh, @jojolepro, @Moxinilian
root: fbxcel - 1 detected crates which regressed due to this; cc @lo48576
root: fui - 1 detected crates which regressed due to this; cc @xliiv
root: lettre_email - 13 detected crates which regressed due to this; cc @amousset
root: liquid - 8 detected crates which regressed due to this; cc @johannhof
root: redis-async - 5 detected crates which regressed due to this; cc @benashford
Regarding redis-async
this was fixed in version 0.4.5 a couple of weeks ago. Those five crates that failed to build have versions 0.4.3 or 0.4.4 in their Cargo.lock
file, but a cargo update
should fix them without any other intervention required.
cc @rust-lang/libs, this was reopened due to the impact found on crater (see above). We'll discuss this in the next triage meeting but figured y'all would want to be aware ahead of time.
fbxcel
has 0.4.x release (which compiles with nightly) and the regressed version is 0.2.0.
Should I release 0.2.1 with a fix?
It's up to you, of course, but if you don't then it's likely that downstream crates which still depend on the 0.2.x series will stop compiling in 1.36+.
FWIW in the build/test crater run which seems to hit more crates I'm seeing numerous regressions beyond even those listed above (if it'd be helpful, I can spend some time preparing a full list, pinging the relevant folks, etc.). However, I'm thinking that we should revert the change that caused this -- the impl doesn't seem sufficiently useful (essentially saving a .clone()
).
Fixed in amethyst by https://github.com/amethyst/amethyst/pull/1619 The next release is scheduled to be out soon.
Fixed in fbxcel 0.2.1.
We discussed this at libs triage again yesterday but reached the same conclusion as before. If anyone has difficulties in migrating though please let us know and we can try to help out!
I suspect this will catch a lot of users by surprise when stable is released. The as_ref
/into
pattern seems to be widely used according to the crater run and our internal crate breakage report.
There have been several questions about why stringVariable.asRef() no longer compiles, particularly with developers using older pinned versions of libraries.
It certainly looks like there was an awareness that this change was going to cause some pain, but there was no mention of the type of errors in the 1.36 announcement or release notes that I saw. I also spent some time looking for documentation on what is considered acceptable breakage, and couldn't find it. (I was surprised it wasn't easy to find on the website.)
Is it worth-while to communicate (more) about acceptable breakage?
My thought is that when an issue this arises, at least acknowledge that 'acceptable breakage' was found during the beta automated testing, and provide at least a link to the GitHub issue in the release notes (and if more explanation is needed, perhaps a blog article).
The stability commitments are explained in this blog post, which I linked in an earlier comment in this thread. I agree that this information deserves a more prominent location.
Specifically AsRef will be hopefully better documented soon (#62586); we've mostly hesitated from doing so in the past because there's technically a ton of possible breakage that users might encounter that is similar to this -- any impl, method added may cause conflicts downstream. I do agree that some way of saying "here's how to fix that" would be great, or at least pointing users at what we already found. But we have no great place to do that today -- the releases.md file isn't a great place. Maybe we can start a page on forge.rust-lang.org or something along those lines.
While I understand this type of breakage is acceptable and falls within stability guarantees, would it have made sense to first add a warning/deprecation notice for one or two releases prior to the actual change? Assuming that is doable without a large effort of course.
There's no infrastructure to do that currently AFAIK.
The following code has been working with stable compiler (rustc 1.34.2), but doesn't compile with nightly (rustc 1.36.0-nightly (963184bbb 2019-05-18)).
code in playground
Error the nightly compiler is given:
However, stable compiler is happy with the code and prints the expected hello world.
Stable compiler:
Nightly compiler: