Partially implement RFC 1647 (`Self` in impl headers)

[petrochenkov]

The name resolution part is easy, but the typeck part contains an unexpected problem.

It turns out that Self type depends on bounds and where clauses, so we need to convert them first to determine what the Self type is! If bounds/where clauses can refer to Self then we have a cyclic dependency.
This is required to support impls like this:

// Found in libcollections
impl<I: IntoIterator> SpecExtend<I> for LinkedList<I::Item> { .... }
                                                      ^^^^^ associated type `Item` is found using information from bounds

I'm not yet sure how to resolve this issue.
One possible solution (that feels hacky) is to make two passes over generics - first collect predicates ignoring everything involving Self, then determine Self, then collect predicates again without ignoring anything. (Some kind of lazy on-demand checking or something looks like a proper solution.)

This patch in its current state doesn't solve the problem with Self in bounds, so the only observable things it does is improving error messages and supporting impl Trait<Self> for Type {}.

There's also a question about feature gating. It's non-trivial to detect "newly resolved" Selfs to feature gate them, but it's simple to enable the new resolution behavior when the feature gate is already specified. Alternatively this can be considered a bug fix and merged without a feature gate.

cc #38864
r? @nikomatsakis
cc @eddyb
Whitespace ignoring diff https://github.com/rust-lang/rust/pull/38920/files?w=1

[eddyb]

FWIW I had solved the cycle problem a few months back (eddyb@204fdb2) and I'm planning to publish that as the next (and final?) PR after #38813.

However I'm taking a (yet another) detour through doing lifetime elision syntactically (w/ name-resolved definitions but nothing based on type/trait resolution), which would allow a more efficient implementation of my fixpoint algorithm (it's backtracking atm so O(n!)), by making random-access HIR -> Ty conversion possible.

[nikomatsakis]

So do we want to wait here for some of @eddyb's work to land instead?

[petrochenkov]

@nikomatsakis
Yes, mostly.
This patch still can be landed independently though (it implements the resolve part and therefore supports impl Trait<Self> for Type {} and provides better error messages and tests).

[petrochenkov]

I'll rebase this tomorrow.

[petrochenkov]

Rebased.

[nikomatsakis]

r? @eddyb -- he's been in this area so is best person to review

[eddyb]

@bors r+

[bors]

📌 Commit f9bdf34 has been approved by eddyb

[bors]

⌛️ Testing commit f9bdf34 with merge df8debf...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing df8debf to master...

[eddyb]

I was working on the on-demand stuff and I just realized this can be made to work with AstConv::get_item_type.
In all fairness, ItemImpl is not hooked up to that in rustc_typeck::collect because of predicate complications, that are fixed on this branch I'm playing with (even if you can't get it from tcx.item_type, that's not needed here).