Skip to content

Refactor propagation to be more explicit #32730

Closed
@nikomatsakis

Description

@nikomatsakis
Contributor

In conjunction with @soltanmm, and with an aim towards enabling lazy normalization, HR-caching, specialization's lifetime dispatch rules, and a number of other things, we should refactor the way we propagate obligations and mutable state through the inference context.

The general idea is to make the result of unification also carry a list of obligations. This can be used by lazy normalizing to carry the results of normalization, but we should also (eventually) move all mutation of the region inference state out and use it to carry region edges that result. This will help simplify the skolemization code, with the lifetime dispatch logic, and with more advanced caching. It might also make sense to eventually move the unification of type variables too, so that unify is a pure function.

At the moment, this issue exists mainly to serve as a placeholder for FIXME, but I hope to expand with a bit more design and also some checklist of to-do items. :)

Activity

added a commit that references this issue on Apr 13, 2016

Auto merge of #32780 - soltanmm:consider-the-following, r=nikomatsakis

soltanmm

soltanmm commented on Jul 5, 2016

@soltanmm

A note (both for myself to walk back to and I guess as a minor update):
Turns out that the obligation plumbing is incomplete AFAICT; switching up the variance appears to drop obligations on the floor. So, that'll happen in another PR before the originally planned next-step of propagating region inference obligations for the Sub and Equate relations over regions.

jroesch

jroesch commented on Aug 23, 2016

@jroesch
Member

cc me

nikomatsakis

nikomatsakis commented on Aug 24, 2016

@nikomatsakis
ContributorAuthor

@soltanmm I have a branch that is using the plumbing now to handle all region obligations. It's not quite right for higher-ranked stuff yet -- but seems to basically work:

failures:
[compile-fail] compile-fail/hr-subtype.rs
[compile-fail] compile-fail/lifetime-bound-will-change-warning.rs
[compile-fail] compile-fail/object-lifetime-default-from-rptr-box-error.rs
[compile-fail] compile-fail/object-lifetime-default-from-rptr-struct-error.rs
[compile-fail] compile-fail/object-lifetime-default-mybox.rs
[compile-fail] compile-fail/regions-bounds.rs
[compile-fail] compile-fail/regions-fn-subtyping-return-static.rs
[compile-fail] compile-fail/regions-infer-at-fn-not-param.rs
[compile-fail] compile-fail/regions-infer-contravariance-due-to-decl.rs
[compile-fail] compile-fail/regions-infer-covariance-due-to-decl.rs
[compile-fail] compile-fail/regions-infer-not-param.rs
[compile-fail] compile-fail/regions-infer-paramd-indirect.rs
[compile-fail] compile-fail/regions-trait-1.rs
[compile-fail] compile-fail/regions-variance-contravariant-use-covariant-in-second-position.rs
[compile-fail] compile-fail/regions-variance-contravariant-use-covariant.rs
[compile-fail] compile-fail/regions-variance-covariant-use-contravariant.rs
[compile-fail] compile-fail/trait-matching-lifetimes.rs
[compile-fail] compile-fail/variance-use-contravariant-struct-1.rs
[compile-fail] compile-fail/variance-use-covariant-struct-1.rs

test result: FAILED. 2465 passed; 19 failed; 13 ignored; 0 measured

nikomatsakis

nikomatsakis commented on Aug 24, 2016

@nikomatsakis
ContributorAuthor
nikomatsakis

nikomatsakis commented on Aug 30, 2016

@nikomatsakis
ContributorAuthor

I've been plugging away on the higher-ranked code. It's coming along, but it's a bit trickier than I naively expected (e.g., I forgot about plug_leaks).

I'm thinking more and more I need to writeup the overall plan here. I still think we're on the right track, but the end-game is complicated. (e.g., in order to make lazy norm and higher-ranked stuff work -- which is of course one of the main motivations -- is going to require some refactoring to better handle higher-ranked reasoning in general.)

Sorry, I know this is vague, just don't have time for such a write-up this second.

added a commit that references this issue on Nov 6, 2016

Auto merge of #37404 - eddyb:lazy-4, r=nikomatsakis

Mark-Simulacrum

Mark-Simulacrum commented on May 13, 2017

@Mark-Simulacrum
Member

@nikomatsakis Could you provide an update on this?

soltanmm

soltanmm commented on May 17, 2017

@soltanmm

IIRC all the reasons to do this are similarly addressed by efforts in Chalk and its eventual integration (though I'm saying this as someone who's been out of the loop for a while).

nikomatsakis

nikomatsakis commented on May 24, 2017

@nikomatsakis
ContributorAuthor

@Mark-Simulacrum getting there, still some FIXMEs related to this issue. I hope to be resolving them soon. (ps @soltanmm, we should chat, I don't have your new e-mail)

added
C-cleanupCategory: PRs that clean code up or issues documenting cleanup.
and removed on Jul 24, 2017
nikomatsakis

nikomatsakis commented on Nov 8, 2017

@nikomatsakis
ContributorAuthor

I'd call this done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-cleanupCategory: PRs that clean code up or issues documenting cleanup.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @nikomatsakis@jroesch@soltanmm@Mark-Simulacrum

        Issue actions

          Refactor propagation to be more explicit · Issue #32730 · rust-lang/rust