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.
9 Likes
You mean this? (Already on nightly; and currently on track for beta backport.)
8 Likes
How am I supposed to run cargo update during cargo install cargo-patch --locked or whatever? Is there some way to override lock file entries from the command line or from ~/.cargo/config?
If the project hasn't been updated by now, it's likely it isn't actively being maintained.
So then what I would do if I really needed it is I'd fork the project, clone the fork, update the deps in that clone, and then cargo install --path /path/to/project.
1 Like
I started to do that, but then the build succeeded on me. Guess it's Uh, how about a release? time.
cargo install cargo-patch just don't pass locked, the flag locks which is exactly the opposite of cargo update.
1 Like
If you need --locked (there are good reasons for it) you should consider pinning the compiler version as well.
rustup install 1.79.0
cargo +1.79.0 install --locked cargo-patch
You'll get warnings about yanked crates, but that's what --locked intentionally buys into.