Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace fallback clauses with projection-equality vs normalization #75

Merged
merged 8 commits into from
Jan 20, 2018

Commits on Jan 19, 2018

  1. add info! to let us follow progress in a less noisy fashion

    Not really the ideal solution, but helpful. It'd be nice to record all
    the data and be able to expand after the fact.
    nikomatsakis committed Jan 19, 2018
    Configuration menu
    Copy the full SHA
    bb7a585 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    22374b4 View commit details
    Browse the repository at this point in the history

Commits on Jan 20, 2018

  1. Configuration menu
    Copy the full SHA
    d1dfe25 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    9304e7f View commit details
    Browse the repository at this point in the history
  3. replace fallback clauses with ProjectionEq/Normalize

    Instead of having "fallback clauses" to handle projection, we now
    have `ProjectionEq(<T as Trait>::Bar = U)`, which can be proven
    either by normalizing *or* by skolemizing.
    
    This required adjusting how we handle elaboration. That is, we now
    "expand" a `T: Trait<Bar = U>` (which is the user syntax for projection
    equality) into `T: Trait` as well, which in turn expands into `WF(T:
    Trait)`. We do this instead of having a clause like:
    
    > `(T: Trait) :- exists<U> { (T: Trait<Bar = U>) }`
    
    This is because that clause caused issues for the recursive solver; in
    particular, `exists<U> { (T: Trait<Bar = U>) }` always resolves to an
    ambiguous result, since there is no unique `U`.
    
    This PR adjusts the tests appropriately. Mostly we add normalize and
    projection. In a few cases, the SLG solver doesn't work yet; those are
    tagged with FIXME (and fixed in a later commit).
    nikomatsakis committed Jan 20, 2018
    Configuration menu
    Copy the full SHA
    c92c25d View commit details
    Browse the repository at this point in the history
  4. Configuration menu
    Copy the full SHA
    0029fc8 View commit details
    Browse the repository at this point in the history
  5. rustfmt resolvent.rs

    nikomatsakis committed Jan 20, 2018
    Configuration menu
    Copy the full SHA
    563a8b0 View commit details
    Browse the repository at this point in the history
  6. substitute answers into pending goals without using unification

    This is not only more efficient, but it also sidesteps the problems that
    led to the SLG solver recursing infinitely when unifying goals involving
    projections.
    
    This also uncovers a potential flaw with the truncation operation, in
    that it does not concern itself with internal binders. For example, we
    might truncate a type like `for<'a> fn(Vec<&'a u32>)` into `for<'a>
    fn(?X)`. This is problematic because there is no value of `?X` that
    could reference `'a`. For now, the SLG solver will panic in this
    scenario, but probably truncation needs to truncate the binder as well.
    nikomatsakis committed Jan 20, 2018
    Configuration menu
    Copy the full SHA
    4ddc058 View commit details
    Browse the repository at this point in the history