Issue 42545 type inference regression

[nikomatsakis]

Fix an ICE that results from type inference obligations being dropped on the floor. Specifically, when computing the implied bounds, we would sometimes do normalizations that get stored in the cache, but we would not try to solve the resulting obligations. This can sometimes leave type variables uninferred. Occurs only rarely because implied bounds are processed in regionck which happens very late, so usually the cache is populated already from somewhere else.

I think that the proper fix here is probably lazy normalization. This fix is intentionally very narrow both because this code is on the chopping block and because this needs a beta backport.

r? @eddyb
cc @arielb1

[eddyb]

@bors r+

[bors]

📌 Commit ef26ac3 has been approved by eddyb

[aidanhs]

@bors r-

Lots of travis failures, e.g.

[00:41:12] error: /checkout/src/test/compile-fail/coherence-impl-trait-for-trait-object-safe.rs:17: unexpected "error": '17:1: 17:37: the trait `NotObjectSafe` cannot be made into an object [E0038]'
[00:41:12] 
[00:41:12] error: 1 unexpected errors found, 0 expected errors not found
[00:41:12] status: exit code: 101
[00:41:12] command: /checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc /checkout/src/test/compile-fail/coherence-impl-trait-for-trait-object-safe.rs -L /checkout/obj/build/x86_64-unknown-linux-gnu/test/compile-fail --target=x86_64-unknown-linux-gnu --error-format json -L /checkout/obj/build/x86_64-unknown-linux-gnu/test/compile-fail/coherence-impl-trait-for-trait-object-safe.stage2-x86_64-unknown-linux-gnu.compile-fail.libaux -C prefer-dynamic -o /checkout/obj/build/x86_64-unknown-linux-gnu/test/compile-fail/coherence-impl-trait-for-trait-object-safe.stage2-x86_64-unknown-linux-gnu -Crpath -O -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers
[00:41:12] unexpected errors (from JSON output): [
[00:41:12]     Error {
[00:41:12]         line_num: 17,
[00:41:12]         kind: Some(
[00:41:12]             Error
[00:41:12]         ),
[00:41:12]         msg: "17:1: 17:37: the trait `NotObjectSafe` cannot be made into an object [E0038]"
[00:41:12]     }
[00:41:12] ]

[nikomatsakis]

Bah. I hadn't considered all the duplicate errors. I'll see what I can do about suppressing those.

[nikomatsakis]

@bors r=eddyb

[bors]

📌 Commit 125968b has been approved by eddyb

[arielb1]

Won't 125968b have the dropck ICE again on code with type errors? Maybe skip calling regionck from wfcheck if there are type errors in https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/wfcheck.rs#L60 - or have smarter span management so that the spans stay the same for both errors, which would get the error deduplicated.

@bors r-

[nikomatsakis]

@arielb1

Won't 125968b have the dropck ICE again on code with type errors?

I don't think so, because that was one of those "delayed bug" things, where it only ICEs if an error is not reported.

have smarter span management so that the spans stay the same for both errors, which would get the error deduplicated.

Do we detect and remove duplicate errors based on span etc already? I had thought about tinkering more, but decided it was better to fix the ICE in a narrow way. Still, I could imagine looking at the obligations individually and assigning the span of the enclosing impl if they do not involve anything "local" to the function.

[arielb1]

@nikomatsakis

Sure. traits::error_reporting does not report duplicate and, since my PR, "implied" errors with the same span.

I don't think so, because that was one of those "delayed bug" things, where it only ICEs if an error is not reported.

Then ok. Feel free to r+, but if you can do something simple with the spans that would be best.

[nikomatsakis]

Sure. traits::error_reporting does not report duplicate and, since my PR, "implied" errors with the same span.

The problem is that these errors are reported at different times, I think, and hence I'm not sure that logic will apply. That is, the one error is occurring (I believe) when we check the WF of the impl, and the other when we are checking the individual methods.

[nikomatsakis]

I verified that they are in different inference contexts, so -- barring significant restructuring -- just tinkering with spans wouldn't cut it.

[nikomatsakis]

@bors r=eddyb

[bors]

📌 Commit 125968b has been approved by eddyb

[nikomatsakis]

@bors r-

Had an idea of how to solve the remaining duplicate error problem.

[nikomatsakis]

@bors r=eddyb

[bors]

📌 Commit 9fec409 has been approved by eddyb

[bors]

⌛ Testing commit 9fec409 with merge dfb8c80...

[bors]

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