{"action":"opened","issue":{"url":"https://api.github.com/repos/rust-lang/rust/issues/32286","repository_url":"https://api.github.com/repos/rust-lang/rust","labels_url":"https://api.github.com/repos/rust-lang/rust/issues/32286/labels{/name}","comments_url":"https://api.github.com/repos/rust-lang/rust/issues/32286/comments","events_url":"https://api.github.com/repos/rust-lang/rust/issues/32286/events","html_url":"https://github.com/rust-lang/rust/issues/32286","id":141286925,"number":32286,"title":"ObligationForest assumptions incorrect","user":{"login":"nikomatsakis","id":155238,"avatar_url":"https://avatars.githubusercontent.com/u/155238?v=3","gravatar_id":"","url":"https://api.github.com/users/nikomatsakis","html_url":"https://github.com/nikomatsakis","followers_url":"https://api.github.com/users/nikomatsakis/followers","following_url":"https://api.github.com/users/nikomatsakis/following{/other_user}","gists_url":"https://api.github.com/users/nikomatsakis/gists{/gist_id}","starred_url":"https://api.github.com/users/nikomatsakis/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nikomatsakis/subscriptions","organizations_url":"https://api.github.com/users/nikomatsakis/orgs","repos_url":"https://api.github.com/users/nikomatsakis/repos","events_url":"https://api.github.com/users/nikomatsakis/events{/privacy}","received_events_url":"https://api.github.com/users/nikomatsakis/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-03-16T14:10:00Z","updated_at":"2016-03-16T14:10:00Z","closed_at":null,"body":"There are two assumptions I made in the Obligation Forest PR that I think may have been incorrect.\r\n\r\n**One.** OF assumes that if selection results in ambiguity the inference context did not change. But, in working on #31867, @soltanmm reminded me that this is not always true, due to the \"unify despite ambiguity\" code.\r\n\r\n**Two.** The `stalled_on` code assumes that the type of a variable will change if any progress can be made. I found this to be true even for closures -- because closures embed the types of their upvars. But this is not *always* true. That is, for closures with no upvars, when we select a closure kind (fn vs fnonce etc), the type doesn't change at all. This became an issue in the projection cache. I was not able however to make a test case that causes a problem with for the OF, but it seems likely to be a problem eventually.\r\n\r\nUltimately I expect the right fix for problem two is to expose the Closure Kind as part of the closure type, so that indeed the fully resolved type *always* changes. It seems very convenient to be able to use the fully resolved type as a cache key and not fear silent background changes.\r\n\r\nThe fix for problem one is just to refactor a bit I think to expose that information better. The only effect it has is when the OF will decide it has reached a fix point and stop trying to call select."}}