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

preliminary model for "opaque types" where hidden types are known #335

Open
nikomatsakis opened this issue Feb 26, 2020 · 4 comments
Open
Assignees
Labels
C-chalk-solve Issues related to the chalk-solve crate current-sprint Being worked on in the current sprint

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Feb 26, 2020

The goal here is to model Rust's impl Trait. For now the starting plan is to have a version where chalk is given both the opaque type declaration and the hidden type:

opaque type T<..>: Bounds = HiddenTy;

Note that opaque types can be generic.

We will model opaque types as an special kind of alias. Like associated types aliases, when an opaque type alias T is equated with some other type U, we will generate an AliasEq(T = U) goal.

The difference is that the two clauses for AliasEq goals work a bit differently. In particular, the "normalization" rule requires a special goal, Reveal, to be in the environment:

AliasEq(T = HiddenTy) :- Reveal.

AliasEq(T = !T).

There are also special rules for the !T placeholder:

Implemented(!T: Bounds). // from the declaration

// for auto traits:
Implemented(!T: AutoTrait) :- Implemented(HiddenTy: AutoTrait).
@nikomatsakis nikomatsakis changed the title model "opaque types" preliminary model for "opaque types" where hidden types are known Feb 26, 2020
@jackh726 jackh726 added the current-sprint Being worked on in the current sprint label Feb 27, 2020
@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Mar 18, 2020

Let's create a check-list of details to take care of

(edit: checklist moved by detrumi to keep it updated)

@flodiebold
Copy link
Member

(@flodiebold do you have an example test?)

How about this (comment in the require_send line to cause a cycle)?

@detrumi
Copy link
Member

detrumi commented Apr 17, 2020

Checklist

(moved the checklist to my own comment to avoid "nikomatsakis mentioned ..." messages when editing the checklist to refer to PRs)

@detrumi
Copy link
Member

detrumi commented Sep 14, 2020

Only one task left: extend WF rules for implied bounds interactions. I can't quite remember what we meant with that, but I think it's something along these lines:

Given this program:

trait Clone { }
trait Iterator where Self: Clone { type Item; }
struct Struct { }
struct Ty { }

opaque type O: Iterator<Item = Struct> = Ty;

Using implied bounds, this can prove the following (see the implied_bounds test):

forall<T> {
    if (T: Iterator<Item = Struct>) {
        T: Clone
    }
}

The same should hold for opaque types, but doesn't:

if (Reveal) {
    O: Clone
}

We might be missing some more WF checks around opaque types, since the program above fails to prove the goal, but only does the WF check once you add impl Iterator for Ty {} (then it fails with "opaque type declaration O does not meet well-formedness requirements")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-chalk-solve Issues related to the chalk-solve crate current-sprint Being worked on in the current sprint
Projects
None yet
Development

No branches or pull requests

4 participants