This PR adds rules for negative implementations. It follows pretty much what the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md) says with 1 main difference:
Instead of positive implementations override negative implementations, this have been implemented in a way that a negative implementation of `Trait` for `T` will overlap with a positive implementation, causing a coherence error.
@nikomatsakis r?
cc #13231
[breaking-change]
If `a.method();` can't be resolved, we first look for implemented traits
globally and suggest those. If there are no such traits found, we only
then fall back to suggesting from the unfiltered list of traits.
This seems to match what clang does on arm, but I cannot do any
experimentation with mips, but it matches how the LLVM intrinsics are
defined in any case...
Unlike the intrinics in C, this types the SSE values base on integer
size. This matches the LLVM intrinsics which have concrete vector types
(`<4 x i32>` etc.), and is no loss of expressivity: if one is using a C
function that really takes an untyped integral SSE value, just give it
whatever Rust type makes most sense.
* Not all traits are part of the prelude anymore
* We switched from pass-by-reference to pass-by-value for most traits
* Add some explanations around pass-by-value traits in the context of
generic code and additional implementations for reference types.
Currently, we build a closure that does nothing but pass its argument
through to another function, this is rather wasteful and creates lots of
unnecessary closures.
While it's unstable and will probably be replaced or "reformed" at some point, it's useful in the mean time to be able to introspect the type system when debugging, and not be limited to sized types.
Fixes#21058
...to make it slightly clearer that there's not much point in boxing a vec.
On a different note, I read the contribution guidelines (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-request-procedure) which say I should update the copyright date for this file. But I can see that nobody else has done this so far this year, despite there being a fair number of commits.
Does that instruction need removing?
