Add support for default trait implementations

[flaper87]

This is one more step towards completing #13231

This series of commits add support for default trait implementations. The changes in this PR don't break existing code and they are expected to preserve the existing behavior in the compiler as far as built-in bounds checks go.

The PR adds negative implementations of Send/Sync for some types and it removes the special cases for Send/Sync during the trait obligations checks. That is, it now fully relies on the traits check rather than lang items.

Once this patch lands and a new snapshot is created, it'll be possible to add default impls for Send and Sync and remove entirely the use of BuiltinBound::{BoundSend,BoundSync} for positive implementations as well.

This PR also removes the restriction on negative implementations. That is, it is now possible to add negative implementations for traits other than Send/Sync

[flaper87]

r? @nikomatsakis

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[nagisa]

Since void structs are warned to be changed into struct Struct;, it would make sense to go for impl !Trait for Struct; syntax rather than impl !Trait for Struct {}.

[flaper87]

@nagisa if we allow that, we should also allow trait Test;, impl Trait for Struct; and impl Trait for ..; otherwise it'd be inconsistent.

[nikomatsakis]

Let's call this DefaultedTrait

[nikomatsakis]

Never mind, let's call it DefaultImpl or something like that.

[flaper87]

I'm terrible with naming things. If we rename this to DefaultImpl, we should probably also rename the Item_ as DefaultImpl instead of DefaultTrait

[nikomatsakis]

This is looking really good. Here is a checklist of things I noticed while reading (it's hard to leave comments on individual commits because I was reading the collapsed diff):

• We need to get the coherence rules right. In particular, for a defaulted trait, you should only be able to do user impls on structs/enums. This is basically a generalization of the rules in librustc_typeck/coherence/impls.rs to apply to defaulted traits as well as builtin bounds.
• I'd like to see more systematic testing, perhaps with a more regular naming convention. That said, I think your tests are about as good as what we currently have anyway. It just seems like there are a lot of cases in constituent_types that we should cover.
• I wonder if we can make send/sync go through the defaulted code paths, even though we can't (yet) add the actual impls we want. That would help us gain confidence in those code paths. We can discuss on IRC what I mean.
• I think the supertrait code in constituent_types is wrong, we shouldn't need to elaborate the supertraits. Defaulted traits do not apply to object types, in fact, since they can close over anything (including some type that opted out of the defaulted trait).

UPDATED the supertrait bullet point

[nikomatsakis]

Some further comments from IRC:

[03:57:43] <nmatsakis> if you have a defaulted trait
[03:57:48] <nmatsakis> right now you just unconditionally add an entry
[03:57:49] <nmatsakis> that's not quite right
[03:58:08] <nmatsakis> I think we want to match on the (shallowly resolved) self-type
[03:58:16] <nmatsakis> if it is a tyvar, we want to set the ambigiuous flag and bail out
[03:58:40] <nmatsakis> if it is an object, we do not add a default candidate (but see later)
[03:58:45] <nmatsakis> if it is anything else, we add a default candidate
[03:59:12] <nmatsakis> for objects, there exists already assemble_candidates_from_object_ty()
[03:59:18] <nmatsakis> I think that should be extended to cover the builtin bounds case
[03:59:37] <nmatsakis> eventually object types should be arbitrary sums
[03:59:41] <nmatsakis> Foo+Bar whre Foo and Bar are traits
[04:00:05] <nmatsakis> but that seems like the most logical place to put it
[04:01:09] <nmatsakis> we'd have to modify the builtin bounds code then to remove that logic from `builtin_bound` -- which should just return ParameterBuiltin for object types, I think
[04:01:18] <nmatsakis> (I'm going to copy this to the PR for future reference)

[bors]

⌛ Testing commit 3dcc631 with merge d15a06a...

[bors]

💔 Test failed - auto-win-64-nopt-t

[Manishearth]

@bors : retry

[bors]

⌛ Testing commit 3dcc631 with merge 812dd9f...

[bors]

💔 Test failed - auto-linux-32-nopt-t

[bors]

💔 Test failed - auto-linux-32-opt

[bors]

💔 Test failed - auto-win-64-opt

[bors]

💔 Test failed - auto-win-32-opt

[alexcrichton]

@bors: retry

[bors]

⌛ Testing commit 3dcc631 with merge ca9b37e...

[bors]

💔 Test failed - auto-mac-64-nopt-t

[nikomatsakis]

@bors retry

curse you!

[bors]

⌛ Testing commit 3dcc631 with merge dc6e06e...

[bors]

💔 Test failed - auto-win-32-nopt-t

[alexcrichton]

@bors: retry

[bors]

⌛ Testing commit 3dcc631 with merge 2890508...

[eddyb]

This... renamed def::DefTrait to def::DefaultImpl and nobody noticed?!

[eddyb]

I am not killing the build because the rest of this patch is important, but someone will have to revert that change.

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t, auto-win-64-opt

[flaper87]

@eddyb that change was obviously unintentional and no-one noticed because the patch is quite big and the rename came in the middle. In other words, assume good faith ;)

I'll revert that change.

[eddyb]

@flaper87 I realized it was sed gone wrong. My UFCS patch is rebased on top of a revert, otherwise rebasing would've been much more painful. I guess I noticed only because I was looking for potential conflicts.

[flaper87]

@eddyb oh awesome, thanks for fixing it, you saved me some revert time :D

[nikomatsakis]

Hey, it landed! 👯

[brson]

🎆