Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upRegression in done-0.0.0-reserve on Rust 1.17 #40192
Comments
brson
added
the
regression-from-stable-to-nightly
label
Mar 1, 2017
This comment has been minimized.
This comment has been minimized.
|
This has to do with a broken implementation of On Rust 1.16.0 the standard I'm not really sure how to classify this, but we'll likely want to talk about this during libs triage. @rust-lang/libs, thoughts here? I'm not sure if there's practical implications to changing to use |
alexcrichton
added
I-nominated
T-libs
labels
Mar 1, 2017
This comment has been minimized.
This comment has been minimized.
|
Buggy code is buggy, IMO. |
This comment has been minimized.
This comment has been minimized.
|
I don't believe there are correctness concerns re float arrays since |
This comment has been minimized.
This comment has been minimized.
|
Interesting. Now we have to decide who is to blame here :) In this implementation So is the specialization to blame then? Well, the specialization rule certainly isn't incorrect. It's merely an optimization that avoids going through several Oh well. Looks like we have to shift the blame onto the user. That said, I'm feeling very sympathetic. The user wrote what they thought was sensible code and it didn't work in very subtle ways. I believe this is what happened... They wanted to have a custom implementation of Unfortunately, implementing Another possible scenario is that the user already had |
This comment has been minimized.
This comment has been minimized.
Why doesn't that compile? That's the pattern I use. |
This comment has been minimized.
This comment has been minimized.
|
@sfackler You're right. Sorry, I've fixed my comment now. But anyways... the point is, it's easier to do the wrong thing by writing |
This comment has been minimized.
This comment has been minimized.
|
@sfackler oh yes that's right (Ord not on floats), so I think the problem here is what we should do in the face of disagreeing Ord/PartialOrd implementations. I'm tempted to say "yes, code can be buggy" in the sense that "libstd can assume that PartialOrd is the same as Ord if both are implemented". |
This comment has been minimized.
This comment has been minimized.
|
There's a clippy lint for the same issue but for |
This comment has been minimized.
This comment has been minimized.
|
Do we have a consensus on this? Suppose that the user derives
Should I believe By this reasoning, I wouldn't classify this issue as a regression, but would like to see rustc emit a warning in cases like this one. |
This comment has been minimized.
This comment has been minimized.
|
Ok we got a chance to discuss this during triage today and the conclusion was that we're going to close this issue. We think it's fair to say that |
alexcrichton
closed this
Mar 14, 2017
This comment has been minimized.
This comment has been minimized.
|
Note that exploring something like a lint in clippy would be great to help catch this! |
brson commentedMar 1, 2017
The source is hard to acquire so here's an equivalent test case:
Not on 1.16.