thread 'rustc' panicked at 'assertion failed: !bounds.has_escaping_bound_vars()'

[dwrensha]

I'm seeing an internal compiler error on the following input (found by fuzz-rustc):

fn test_ref(x: &u32) -> impl std::future::Future<Output = u32> + '_ {
    *x
}

fn main() {
    let _ = test_ref &u;
}

$ rustc main.rs
error[E0425]: cannot find value `u` in this scope
 --> main.rs:6:23
  |
6 |     let _ = test_ref &u;
  |                       ^ not found in this scope

error[E0277]: the trait bound `u32: std::future::Future` is not satisfied
 --> main.rs:1:25
  |
1 | fn test_ref(x: &u32) -> impl std::future::Future<Output = u32> + '_ {
  |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::future::Future` is not implemented for `u32`
2 |     *x
  |     -- this returned value is of type `u32`
  |
  = note: the return type of a function must have a statically known size

thread 'rustc' panicked at 'assertion failed: !bounds.has_escaping_bound_vars()', src/librustc_typeck/check/method/mod.rs:390:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.45.0-nightly (7f65393b9 2020-05-01) running on x86_64-unknown-linux-gnu

error: aborting due to 2 previous errors

[dwrensha]

Possibly related to #70813, though the panic happens at a different place.

[dwrensha]

Report from cargo-bisect-rustc:

searched nightlies: from nightly-2020-03-01 to nightly-2020-05-02
regressed nightly: nightly-2020-03-28
searched commits: from 2fbb075 to 7520894
regressed commit: 7b73d14

[estebank]

It is caused by a different underlying cause to #70813.

[estebank]

The underlying issue is a bad interaction in the following code 7b73d14#diff-18d99e659faf20ef0968cc7bad7f81b2R498-R513 with the call to lookup_op_method_in_trait (called by lookup_op_method) which expects there not to be any unresolved lifetimes. This happens because the code test_ref &u; is actually parsed and evaluated as test_ref & u; (test_ref and u).