]> git.lizzy.rs Git - rust.git/commit
Auto merge of #37294 - nikomatsakis:issue-37154, r=nikomatsakis
authorbors <bors@rust-lang.org>
Sat, 22 Oct 2016 10:30:23 +0000 (03:30 -0700)
committerGitHub <noreply@github.com>
Sat, 22 Oct 2016 10:30:23 +0000 (03:30 -0700)
commit4879166194ed63ebd2a8c3ce8db1ccde4a6a1920
tree8e191844bd43b1c82aff73119cf182659920fab3
parent4642e08b4d00e350555e18c72a109c2a9d502d76
parent483bc864cafe871bfeb82e44a804ed7ea49442a0
Auto merge of #37294 - nikomatsakis:issue-37154, r=nikomatsakis

remove keys w/ skolemized regions from proj cache when popping skolemized regions

This addresses #37154 (a regression). The projection cache was incorrectly caching the results for skolemized regions -- when we pop skolemized regions, we are supposed to drop cache keys for them (just as we remove those skolemized regions from the region inference graph). This is because those skolemized region numbers will be reused later with different meaning (and we have determined that the old ones don't leak out in any meaningful way).

I did a *somewhat* aggressive fix here of only removing keys that mention the skolemized regions. One could imagine just removing all keys added since we started the skolemization (as indeed I did in my initial commit). This more aggressive fix required fixing a latent bug in `TypeFlags`, as an aside.

I believe the more aggressive fix is correct; clearly there can be entries that are unrelated to the skoelemized region, and it's a shame to remove them. My one concern was that it *is* possible I believe to have some region variables that are created and related to skolemized regions, and maybe some of them could end up in the cache. However, that seems harmless enough to me-- those relations will be removed, and couldn't have impacted how trait resolution proceeded anyway (iow, the cache entry is not wrong, though it is kind of useless).

r? @pnkfelix
cc @arielb1