-
Notifications
You must be signed in to change notification settings - Fork 182
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
Well-formedness checking of declarations #11
Comments
Probably the first step to tackling this bug is breaking it into steps and opening issues on those =) |
withoutboats
added a commit
to withoutboats/chalk
that referenced
this issue
Mar 14, 2017
Preparation for resolving rust-lang#11.
withoutboats
added a commit
to withoutboats/chalk
that referenced
this issue
Mar 14, 2017
Preparation for resolving rust-lang#11.
@nikomatsakis can you provide some guidance on what those steps might be? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We don't currently do any WF checking. Specifically, it'd be nice to lower each struct/trait/impl into a predicate that, if provable, defines whether the declaration is well-formed. In most cases this is relatively straightforward, though depending how far we go we might need to extend the IR.
For example, structs don't currently list their fields, but the WF rules for structs require that the type of each field is WF. So if we had a struct:
Then the WF predicate for
Foo
might look like:This relies on us having the rules for when types are well-formed (which...I think we do? if not, should open a bug on that), which would look like:
In this case, that would be unprovable, and hence the
struct Foo
is not considered well-formed (not without aT: Eq
where-clause, at least). If we added theT: Eq
where clause:then we would have:
and everything is provable again.
The text was updated successfully, but these errors were encountered: