Anonymous bound region BrAnon(0) in return but not args

[dtolnay]

Looks just like #43567. Mentioning @petrochenkov and @eddyb who were involved in that issue. The following code compiles with 1.21.0 but ICE as of 1.22.0.

fn f(_: X) -> X {
    unimplemented!()
}

type X<'a> = <&'a () as Trait>::Value;

trait Trait {
    type Value;
}

impl<'a> Trait for &'a () {
    type Value = ();
}

fn main() {}

error: internal compiler error: librustc_typeck/astconv.rs:1212: anonymous bound region BrAnon(0) in return but not args
 --> src/main.rs:1:15
  |
1 | fn f(_: X) -> X {
  |               ^

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.25.0-nightly (da569fa9d 2018-01-16) running on x86_64-unknown-linux-gnu

[eddyb]

cc @nikomatsakis Looks like astconv is eagerly normalizing, but not when checking the return.
fn f<'a>(x: X<'a>) -> X<'a> { x } produces a non-ICE error which is also wrong (IMO).

[nikomatsakis]

triage: P-high

[topecongiro]

rust/src/librustc_typeck/astconv.rs

Line 1207 in ab7abfc

let late_bound_in_ret = tcx.collect_referenced_late_bound_regions(&output);

Is changing collect_referenced_late_bound_regions to collect_constrained_late_bound_regions ok?

My understanding is that fn f<'a>(x: X<'a>) -> X<'a> is ok, whereas fn g<'a>(x: X<'a>) -> &'a X<'a> is not and rustc should produce an error.

[nikomatsakis]

OK, looked a bit closer. I think the code is correct, but the span_bug was just there to catch an edge-case in the error message formation that I didn't feel like handling (and thought was impossible) -- in particular, the case where a region is anonymous and yet somehow appears only in the return type.

I thought this was impossible because the elision code (which kicks in in such a case) ought to have detected that and repored an error. For example, fn foo() -> &u32 will error out in a different way.

But I overlooked the fact that there could be a lifetime which appeared in the parameters but was not constrained by the parameters. In particular, type and lifetime inputs to an associated type are not constrained (which is of course what we have here, though the use of a type-alias kind of hides it).

So I think we basically just want to tweak the error message code in this case.

[nikomatsakis]

Hmm, actually, while we can simply fix the error message, I'm now second guessing if this is the right place to detect an error, or if this should be an error at all. We could certainly handle it (alternatively) by treating the anonymous lifetime as an early-bound region.

[nikomatsakis]

Well, I opened a PR to fix the ICE, anyway.