The breaking change here was a new trait implementation. You can’t have a trait implementation only exist for certain crates in a dependency tree and not for others.
3 Likes
No, this is not possible.
What you can do is to exclude a trait impls from type inference, just for certain versions of time. The impl still exists though, it's just never inferred and otherwise doesn't introduce ambiguity.
I was just restating this but rather than being edition based, it could be restricted to just time.
This can be made to work because type inference is purely local to a crate; what gets inferred in a crate doesn't affect how other crates behave. So different crates can have different behavior in type inference. This is unlike the actual set of trait impls, which must be coherent across all crates.
1 Like
I remember there was a compiler exception added to just a type of the bevy crate: Tracking Issue for Bevy special-casing of implied bounds and `-Zno-implied-bounds-compat` · Issue #119956 · rust-lang/rust · GitHub
So also adding an exception for time to make it compile just like it compiled before1.80 isn't that far fetched. It would be functionally equivalent to patching certain versions of the crate to add the required type annotations, but without actually changing the source code (and thus not affecting reproducibility) - instead it would tweak the type inference algorithm.
4 Likes
Let's establish a baseline mitigation we know we can do: Add a note to the rustc error message (or possibly to cargo) instructing the user to update their version of the time crate with cargo update -p time. This will still be a papercut, but a much gentler one.
If we come up with a better and more ambitious mitigation, that can replace the message, but let's not let the perfect become the enemy of doing something good here.
8 Likes
You mean this? (Already on nightly; and currently on track for beta backport.)
8 Likes