DSTify [T]/str extension traits

[japaric]

This PR changes the signature of several methods from foo(self, ...) to foo(&self, ...)/foo(&mut self, ...), but there is no breakage of the usage of these methods due to the autoref nature of method.call()s. This PR also removes the lifetime parameter from some traits (Trait<'a> -> Trait). These changes break any use of the extension traits for generic programming, but those traits are not meant to be used for generic programming in the first place. In the whole rust distribution there was only one misuse of a extension trait as a bound, which got corrected (the bound was unnecessary and got removed) as part of this PR.

I've kept the commits as small and self-contained as possible for reviewing sake, but I can squash them when the review is over.

See this table to get an idea of what's left to be done. I've already DSTified Show and I'm working on Hash, but bootstrapping those changes seem to require a more recent snapshot (#18259 does the trick)

r? @aturon
cc #16918

[rust-highfive]

Warning

• These commits modify unsafe code. Please review it carefully!

[aturon]

OK, I've gone through the PR and it looks great to me. Thanks for taking this on! I'll r+ after a squash.

[japaric]

Squashed. @aturon re-r?

[japaric]

@aturon Rebased. re-r?

[ftxqxd]

Should BoxedSlice be DSTified by this PR as well? It’s implemented by Box<[T]> only, so it could perhaps be merged into MutableSliceAllocating as a method taking self: Box<[T]>.

Perhaps slightly off-topic, but shouldn’t MutableSlice and ImmutableSlice be merged into one trait, and similar merges done with the Ord, Clone etc. equivalents? And what’s the difference between CloneableVector and ImmutableCloneableVector? I suppose there are enough things wrong with the slice extension traits that those sorts of changes should be left to another PR, perhaps.

[japaric]

Should BoxedSlice be DSTified by this PR as well? It’s implemented by Box<[T]> only, so it could perhaps be merged into MutableSliceAllocating as a method taking self: Box<[T]>.

I think UFCS still needs more work to do this, because Box<Self>/Box<self> is not working yet. At least this didn't work as expected:

trait BoxedSlice_<T> for Sized? {
    //fn into_vec_(Box<self>) -> Vec<T>;  //~ error: expected identifier, found keyword `self`
    fn into_vec_(Box<Self>) -> Vec<T>;
}

impl<T> BoxedSlice_<T> for [T] {
    fn into_vec_(slice: Box<[T]>) -> Vec<T> {
        unimplemented!();
    }
}

fn main() {
    let v: Box<[u8]> = box [0u8, 1, 2];
    println!("{}", v.into_vec_());
    //~^ error: type `Box<[u8]>` does not implement any method in scope named `into_vec_`
}

Perhaps slightly off-topic, but shouldn’t MutableSlice and ImmutableSlice be merged into one trait, and similar merges done with the Ord, Clone etc. equivalents? And what’s the difference between CloneableVector and ImmutableCloneableVector? I suppose there are enough things wrong with the slice extension traits that those sorts of changes should be left to another PR, perhaps.

I think the idea is to reduce the number of extension traits as much as possible (also see #16862), but I wasn't 100% sure so I didn't try that in this PR.

[aturon]

@P1start

I plan to make a PR merging various extension traits and generally cleaning up the prelude traits after this PR lands. But it's fine to do the DST-ification first.

[ftxqxd]

(@japaric It does work if you write self: Box<Self> in the trait declaration and self: Box<[T]> in the implementation but I think what you wrote should work once UFCS is fully implemented. But it does make sense to leave that change for another PR.)