Emerentius / ord_subset

Tools for working with types where a subset of values has a total order, like e.g. floats without NaN
Apache License 2.0
12 stars 1 forks source link

warn(where_clauses_object_safety) on recent nightly #4

Open adeschamps opened 6 years ago

adeschamps commented 6 years ago

On recent nightlies, OrdSubsetSliceExt triggers the where_clauses_object_safety warning:

https://github.com/rust-lang/rust/issues/51443

warning: the trait `slice_ext::OrdSubsetSliceExt` cannot be made into an object
  --> src/slice_ext.rs:42:5
   |
42 | /     fn ord_subset_sort(&mut self)
43 | |     where
44 | |         Self: AsMut<[T]>,
45 | |         T: OrdSubset;
   | |_____________________^
   |
   = note: #[warn(where_clauses_object_safety)] on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #51443 <https://github.com/rust-lang/rust/issues/51443>
   = note: method `ord_subset_sort` references the `Self` type in where clauses

(+3 other similar warnings)

$ rustc --version
rustc 1.29.0-nightly (6a1c0637c 2018-07-23)

I don't have time right now, but I'll try to come back to this in a week or so.

Emerentius commented 6 years ago

Thanks for bringing this up again. The PR #3 is also about this issue.

I'm a bit conflicted on what's best to do here. The issue says ideally it would never become a hard error, in which case I'd just allow the lint. The trait does not exist to make trait objects out of it. If it does become a hard error, then people's code will be broken from what's a minor dependency at best and I'd really like to avoid that.

On the other hand, accomodating the lint is a breaking change, even though very little code would likely be broken.

Emerentius commented 6 years ago

I've looked a bit into the issue on the Rust repo and from what I could gather, the affected code won't be disallowed in the future, only the ability to create trait objects from such traits. But OrdSubsetSliceExt isn't dyn capable anyway, because it contains generic functions.
The warning is just a false positive. However, because I can't #[allow()] future compatibility lints, I'm kind of stuck here. I'm not going to release a breaking change to workaround a buggy lint.

adeschamps commented 6 years ago

That seems reasonable to me. I understand that it's a tricky situation. Probably better to wait and see what happens to that lint.

Emerentius commented 2 years ago

I don't see the warning anymore. It looks like this has been fixed upstream, but I couldn't find the change to rustc that made it happen. I didn't find anything referenced from the issue in the OP nor in the PRs containing the string where_clauses_object_safety.