Having ordered_float anywhere in the dependency chain causes ambiguous Add applications to fail with a very, very long error message #91
Comments
|
Hmm, this is unfortunate. I'm guessing this was caused by cd01fca which added more implementations for Unfortunately, removing those impls now would be a breaking change. (And they are legitimately useful in some cases, so it would be nice to keep them.) But that error is pretty bad! For now, you might be able to work around this problem by downgrading ordered float with: but this won't work if you depend on other crates that specify a newer version. I'll try to figure out a better long-term solution... |
|
For testing purposes, could you provide a complete example of code that compiles without struct MyType;
impl std::ops::Add for MyType {
type Output = Self;
fn add(self, _: Self) -> Self {
MyType
}
}
fn foo() {
let y = MyType;
let f = |x| x + y;
}(If you don't have time to create a reduced test case, a link to your full project would work, if it's somewhere I can access.) |
|
Maybe related to rust-lang/rust#85063? |
|
It's closed source unfortunately, but I'll work on a repro that isn't. In the meantime, explicitly borrowing both the left and right-hand side of the Add op and the Add trait impl might do it |
|
wow, turns out this is really hard to get a minimal reproducing case for. I've tried a lot of stuff, and I just can't seem to get this to happen again in a sandbox environment! I'll keep trying, and will let you know if I figure out anything (and hopefully someone else runs into this bug and can find a reproducer!) |
|
Probably related to this compiler bug: rust-lang/rust#39959 |
|
Here's a minimal example that works without use ordered_float::*; // Comment out this line to suppress the bug.
fn test<T>(p: T) -> T
where
for<'a> &'a T: std::ops::Sub<&'a T, Output = T>,
{
&p - &p
}
fn main() {
println!("{:?}", test(0.0_f64));
}Error message: Beers are on me for anyone who fixes this bug. |
|
Thanks for the reduced test case! |
|
Not sure if this is helpful, but I also ran into this as soon as I updated to the latest ordered_float version. Interestingly, in a huge (closed source, unfortunately) code-base, it only triggered on one add operation! Thank you @lemmih for the awesome reduced test case. I'm going to link your repro to the rustc bug report that you linked to if you don't mind. |
|
I just hit this issue as well. The code that triggered it: // All the pod's containers are ready
pod
.status
.as_ref()
.and_then(|status| status.container_statuses.as_ref())
.map(|container_statuses| {
container_statuses
.iter()
.all(|container_status| container_status.ready)
})
.unwrap_or_default()
This was a bit of a head-scratcher considering that I'm not using |
|
I also encountered this issue when I tried to build a crate on |
|
Unfortunately, the issue is there, it's basically impossible to use the crate. A recursive error will popup in the place of most other errors in Rust analyzer, "covering" real error. You can't really work like that. Issue disappears when rolling back to 1.1.0 version of this crate. |
|
Fixed in ordered-float 3.0.0 by removing the offending impls. The fix is here: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Recently, updating my dependencies in a project that depends on
metricscaused my build to fail in a place it wasn't failing previously due to a place where we were depending on the default type inference rules forstd::ops::Addto infer the type of an argument to a closure - something like:Simply having ordered_float in the dependency tree for my project - not even depended on directly! - causes that code to now fail with the following error message:
(make sure to scroll to the right there - github's lack of wrapping for code blocks really doesn't do the size of the error message justice)
The text was updated successfully, but these errors were encountered: