save-analysis: Pull associated type definition using qpath_def

[Xanewok]

Closes rust-lang/rls#1390

This (probably?) fixes the case where we run the save-analysis code on the following snippet:

trait Test<'a> {
    type Thing: Test2;
}

trait Test2 {
    fn print();
}

#[allow(unused)]
fn example<T>(t: T)
    where T: for<'a> Test<'a>
{
    T::Thing::print(); //~ ERROR cannot extract an associated type from a higher-ranked trait bound in this context
    // ^ only errors in save-analysis mode
}

The chain is as follows:

• culprit is hir_ty_to_ty
• which calls ast_ty_to_ty in the ItemCtxt
• which calls associated_path_to_ty
• which finally fails on projected_ty_from_poly_trait_ref
  

  rust/src/librustc_typeck/collect.rs

  Lines 212 to 224 in 3de0106

  	if let Some(trait_ref) = poly_trait_ref.no_bound_vars() {
  	self.tcx().mk_projection(item_def_id, trait_ref.substs)
  	} else {
  	// no late-bound regions, we can just ignore the binder
  	span_err!(
  	self.tcx().sess,
  	span,
  	E0212,
  	"cannot extract an associated type from a higher-ranked trait bound \
  	in this context"
  	);
  	self.tcx().types.err
  	}

I'm not exactly sure why hir_ty_to_ty fails - is it because it needs more setup from typeck to work correctly? I'm guessing the fix is okay since we just pull the already typeck'd data (we run save-analysis after all the analysis passes are complete) from the tables.

With this change we can 'go to def' on all segments in the T::Thing::print() path.

[rust-highfive]

r? @cramertj

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

[cramertj]

r? @eddyb

[eddyb]

cc @oli-obk @Manishearth We should maybe have an issue for getting clippy off of this.

[Manishearth]

cc @flip1995 in case this is on your list of clippy utilities

[eddyb]

@bors r+

[bors]

📌 Commit bcd263e has been approved by eddyb

[cuviper]

FWIW, this fix for rust-lang/rls#1390 was requested on reddit:
https://www.reddit.com/r/rust/comments/boj6wk/announcing_rust_1342_rust_blog/enhmg3p/

[Xanewok]

@pietroalbini @rust-lang/release should this be backported?

[cuviper]

@Xanewok only when/if it gets beta-accepted by the compiler team.

[Xanewok]

only when/if it gets beta-accepted by the compiler team.

I imagined this decision has always been made primarily by release/infra teams, just wanted to bring this to their attention since the backport window will close soon.

Let's try with another team: @rust-lang/compiler should this be backported? This fixes save-analysis compilation for gstreamer (and also for its reverse deps). It was requested in rust-lang/rls#1390 (comment) and also on reddit, as @cuviper pointed out.

[pietroalbini]

I imagined this decision has always been made primarily by release/infra teams, just wanted to bring this to their attention since the backport window will close soon.

Decisions for beta backports are made by the team responsible for the area of the codebase affected by the changes (most of the time compiler, sometimes libs or rustdoc), and the release team doesn't have a say on what gets backported.

For stable backports the process for beta still applies, and in addition to that the release team has to approve the point release as a whole.

[pnkfelix]

discussed at T-compiler meeting. approved for beta-backport.