Fix ICE from #33364 by selectively skipping confirmation pass. #34573

pnkfelix · Jun 30, 2016

Fix #33364: during trans, confirmation should never fail (because type check has already admitted the source code).

So skip confirmation in that context, unless there is some reason (i.e. unresolved unification variables, or a type undering a Binder for region variables) during projection of an associated item) that we still need to run it.

rust-highfive · Jun 30, 2016

r? @nikomatsakis

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

pnkfelix · Jun 30, 2016

Oh I need to add the regression test too.

brson · Jun 30, 2016

Thanks @pnkfelix ! cc @rust-lang/compiler This regression fix needs to land before monday/tuesday to get into 1.10.

eddyb · Jun 30, 2016

eddyb reviewed Jun 30, 2016

View changes

eddyb · Jun 30, 2016

src/librustc/traits/project.rs

+    if selcx.projection_mode().is_any() {
+        // Issue #33364: `ProjectionMode::Any` means trans, during
+        // which there is no (good) reason for confirmation to fail
+        // (because type check has already admitted the source code).


That's not necessarily true if anything does probing (such as checking if a vtable needs to contain a specific method, based on where clauses of that method).

@eddyb Wait so are you saying it is not actually sound for me to skip the confirms via the logic I have put here?

Or ... are you "merely" saying that the comment as written here is misleading?

I'm not sure in which situations this may backfire, but for example, vtable building in trans probes for obligations on methods to decide whether to include them. There are also secondary probes related to specialization, during selection.

arielb1 · Jun 30, 2016

#33364 is a regression from 1.8 to 1.9 - it already hit stable.

arielb1 · Jul 2, 2016

De-beta-nominating since not a relevant regression.

nikomatsakis · Jul 7, 2016

nikomatsakis reviewed Jul 7, 2016

View changes

nikomatsakis · Jul 7, 2016

src/librustc/traits/project.rs

@@ -1247,6 +1247,34 @@ fn confirm_callable_candidate<'cx, 'gcx, 'tcx>(
                                              fn_sig,
                                              flag);

+    if selcx.projection_mode().is_any() {


Hmm. This is somehow hackier than I had imagined. What I had hoped was that we would attach a (generic) filter function to the FulfillmentContext -- when not in trans, this filter function would accept all work, but within trans, it could be more selective.

EDIT: Not that it wouldn't necessarily always be more selective.

I actually told @pnkfelix about ProjectionMode::Any, he had some finer-grained flag initially.

I'm not sure I understand what situations this hack can produce invalid results in.
Remember that trans doesn't just look for things that are guaranteed to succeed, but also has to be able to correctly tell if something would succeed (for various reasons pointed out in a comment above).

@eddyb

Remember that trans doesn't just look for things that are guaranteed to succeed, but also has to be able to correctly tell if something would succeed (for various reasons pointed out in a comment above).

Sometimes yes. It depends on context. This is why I was imagining a filter that the context can provide. =)

Certainly the majority of cases though trans is doing a lot more work than it ought to, just re-resolving things that it knows will pass (and which sometimes yield ICEs when they stumble over other bugs, as in this case).

I'd like to try to make more progress on this, but I also want to make sure I understand the conversation here.

In particular, @nikomatsakis, when you wrote above that you expected a filter to be attached to the FulfillmentContext, did you mean that, or did you mean SelectionContext?

(I ask because I can at least see how a SelectionContext would connect up to the code as written, but attaching it to the FulfillmentContext seems like ... its leaving out details about how that filter would actually prevent this particular confirmation while not messing things up elsewhere. I have no intuition right now as to where the filter fundamentally belongs)

(for those following along this thread, niko left a comment below saying "I meant FulfillmentContext, but I may be incorrect.")

alexcrichton · Jul 14, 2016

triage: beta-nominated

We'll probably want to backport this to ensure the ICE fix gets out soon, even though it's ICE'ing on stable as well. (so long as the compiler team approves of the backport, of course)

nikomatsakis · Jul 20, 2016

@pnkfelix well, I meant FulfillmentContext, but I may be incorrect.

nikomatsakis · Jul 26, 2016

OK, so, I dug a bit more into the approach that I had been advocating for @pnkfelix. I still think that adding a predicate to the FulfillmentContext is a good idea for optimization purposes, but unfortunately it alone was never enough to work around the ICE -- and the other change, which required separating out the OutputTypeParameterMismatch code so that it could be filtered, leads to a complication in projection (where projection succeeds where it ought to fail). I think @pnkfelix tried to talk to me about this while I was on vacation but I did not understand. It seems plausible that we could work around it, but this is a lot of work for what is ultimately a work-around, so I am warming up to a hacky change like the one that @pnkfelix wound up taking on this PR.

bors · Aug 17, 2016

☔️ The latest upstream changes (presumably #35605) made this pull request unmergeable. Please resolve the merge conflicts.

nikomatsakis · Aug 17, 2016

Sorry I've been slow here. I still feel uncomfortable with trying to decide the right fix.

nikomatsakis · Oct 17, 2016

@pnkfelix and I talked the other day. We want to take a shot at pursuing a somewhat more principled fix here, but this kind of hack is still a possibility. =) Going to close this PR in any case for now.

pnkfelix added some commits Jun 29, 2016

Avoid ICE'ing due to panic in `lookup_item_type` in Debug impls.

d234bf9

Provide more info when `TraitRef::to_predicate` hits escaping region …
…bug.

1366cb7

rust-highfive assigned nikomatsakis Jun 30, 2016

pnkfelix added the beta-nominated label Jun 30, 2016

pnkfelix referenced this pull request Jun 30, 2016
Open
ICE: OutputTypeParameterMismatch in failing to resolve associated type as tuple. #33364

brson added the T-compiler label Jun 30, 2016

arielb1 removed the beta-nominated label Jul 2, 2016

nikomatsakis closed this Oct 17, 2016

rust-lang/rust

Join GitHub today

Fix ICE from #33364 by selectively skipping confirmation pass. #34573

Conversation

pnkfelix commented Jun 30, 2016

pnkfelix added some commits Jun 29, 2016

rust-highfive assigned nikomatsakis Jun 30, 2016

This comment has been minimized.

rust-highfive commented Jun 30, 2016

pnkfelix added the beta-nominated label Jun 30, 2016

This comment has been minimized.

pnkfelix commented Jun 30, 2016

pnkfelix referenced this pull request Jun 30, 2016

pnkfelix added some commits Jun 29, 2016

This comment has been minimized.

brson commented Jun 30, 2016

brson added the T-compiler label Jun 30, 2016

eddyb reviewed Jun 30, 2016 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

arielb1 commented Jun 30, 2016

arielb1 removed the beta-nominated label Jul 2, 2016

This comment has been minimized.

arielb1 commented Jul 2, 2016

nikomatsakis reviewed Jul 7, 2016 View changes

This comment has been minimized.

nikomatsakis Jul 7, 2016 • edited

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

alexcrichton commented Jul 14, 2016

This comment has been minimized.

nikomatsakis commented Jul 20, 2016

This comment has been minimized.

nikomatsakis commented Jul 26, 2016

This comment has been minimized.

bors commented Aug 17, 2016

This comment has been minimized.

nikomatsakis commented Aug 17, 2016

This comment has been minimized.

nikomatsakis commented Oct 17, 2016

nikomatsakis closed this Oct 17, 2016

eddyb reviewed Jun 30, 2016

View changes

nikomatsakis reviewed Jul 7, 2016

View changes

nikomatsakis Jul 7, 2016 •

edited