libcore: DST-ify AsSlice, Equiv, and ops traits

[aturon]

This PR changes AsSlice to work on unsized types, and changes the
impl for &[T] to [T]. Aside from making the trait more general,
this also helps some ongoing work with method resolution changes.

This is a breaking change: code that uses generics bounded by AsSlice
will have to change. In particular, such code previously often took
arguments of type V where V: AsSlice<T> by value. These should now
be taken by reference:

fn foo<Sized? V: AsSlice<T>>(v: &V) { .. }

A few std lib functions have been changed accordingly.

The PR also relaxes constraints on generics and traits within the
core::ops module and for the Equiv trait.

[breaking-change]

r? @nikomatsakis
cc @japaric

[japaric]

@aturon These impls probably need an extra Sized? as well:

libcollections/vec.rs:impl<T: PartialEq, V: AsSlice<T>> Equiv<V> for Vec<T> {
libcollections/vec.rs:impl<T: Clone, V: AsSlice<T>> Add<V, Vec<T>> for Vec<T> {
libcore/slice.rs:impl<T: PartialEq, V: AsSlice<T>> Equiv<V> for [T] {
libcore/slice.rs:impl<'a,T:PartialEq, V: AsSlice<T>> Equiv<V> for &'a mut [T] {
libgraphviz/maybe_owned_vec.rs:impl<'a, T: PartialEq, V: AsSlice<T>> Equiv<V> for MaybeOwnedVector<'a, T> {

[japaric]

(Last time I looked at this code, I had the impression that this method could be changed to normalize(&[u8]) (no need for generics), but I didn't look further)

[nikomatsakis]

From my part, r+. These changes look fine to me. But @japaric is presumably right about the other impls.

[aturon]

I pushed an update to add Sized? to the impls that @japaric suggested. Doing so required DST-ifying more of core::ops and the Equiv trait; I went ahead and added Sized? throughout those traits.

I've looked for generic code over these traits for further places to add Sized?, but the only ones that might apply are slated for removal due to collections or numerics reform.

@japaric Want to take a look as well and make sure I didn't miss something?

[japaric]

LGTM

[alexcrichton]

This impl breaks concat_vec for &[Vec<T>] (breaking tests below).

[aturon]

OK, this turns out to be somewhat subtle, because sometimes generic code really needs to work with AsSlice by value rather than by reference, and that in turn means we need impls for references to slices, not just slices. Ideally we'd do something like:

impl<'a, T, Sized? U: AsSlice<T>> AsSlice<T> for &'a U {
    #[inline(always)]
    fn as_slice<'a>(&'a self) -> &'a [T] { self.as_slice() }
}

impl<'a, T, Sized? U: AsSlice<T>> AsSlice<T> for &'a mut U {
    #[inline(always)]
    fn as_slice<'a>(&'a self) -> &'a [T] { self.as_slice() }
}

but this is currently not working due to, I think, some weakness in method resolution that @nikomatsakis is fixing. Will investigate.

[japaric]

FWIW, I usually write such methods as:

impl<'a, T, Sized? U: AsSlice<T>> AsSlice<T> for &'a U {
    #[inline(always)]
    fn as_slice<'a>(&'a self) -> &'a [T] { AsSlice::as_slice(*self) }
}

Otherwise, I end up hitting infinite recursion errors.

[aturon]

(In particular, adding these impls causes the .as_slice() method to no longer be available on String.)

[aturon]

@japaric Ah yes, of course, thanks.

[alexcrichton]

ping @aturon, needs a rebase

[aturon]

@alexcrichton This is blocked on @nikomatsakis's method dispatch changes landing.

[nikomatsakis]

@aturon unblocked now, I guess?

[nikomatsakis]

I'm going to unassign myself and assign to @aturon since it just needs rebasing and tender love and care at this point.

[nikomatsakis]

Hmm, I think this means we can remove the horrible "auto-ref-ref" hack in the method resolution code.