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

Error constraints not sufficiently bubbled up #910

Closed
yav opened this issue Sep 24, 2020 · 4 comments
Closed

Error constraints not sufficiently bubbled up #910

yav opened this issue Sep 24, 2020 · 4 comments
Assignees
Labels
bug Something not working correctly typechecker Issues related to type-checking Cryptol code.

Comments

@yav
Copy link
Member

yav commented Sep 24, 2020

The following definition is incorrectly accepted:

f x = x @ (2 /. 2)

Error constraint should never be generalized over, but some how they are.

Main> :t f
f : {n,
     a} ((error: Type 'Rational' is not an integral type.) Integral Rational) =>
      [n]a -> a
@yav yav added bug Something not working correctly typechecker Issues related to type-checking Cryptol code. labels Sep 24, 2020
@yav yav self-assigned this Sep 24, 2020
@yav
Copy link
Member Author

yav commented Sep 24, 2020

This is related to defaulting: currently if we have Literal K a and both Integral a and Field a we default a to Rational. The error happens because we are also assuming that defaulting would always result in satisfying assumptions and so we don't check for errors after.

There are a few possible solutions:

  1. Don't default in this case. I tried this, and it works but the definition is still accepted, it is just that now it has a constraint that has both Integral and Field on the same variable, so it is still useless.
  2. Default like before, but then check for errors afterwards. Defaulting to incorrect types seems a bit weird, and I am not sure if this might be confusing because we'd get an error like Rational is not Integral when there are no visible rationals around.
  3. Do option (1), and maybe add some machinery to the solver to report and error if it notices incompatible constraints like the above.

I'd say 3 is the "right thing" to do, but is also probably more work than the others. Thoughts? @robdockins @brianhuffman

@yav
Copy link
Member Author

yav commented Sep 24, 2020

There are also similar interactions with FLiteral, so we probably don't want to allow Integral and FLiteral at the same time.

@brianhuffman
Copy link
Contributor

We can already have situations in type checking where two type constraints contradict each other, right? The common case would be contradictory predicates on numeric types. But now with Integral a and Field a we can have contradictory constraints on value types as well. I suppose we should try to handle both cases in a similar way.

@yav
Copy link
Member Author

yav commented Sep 24, 2020

I pushed a fix along the lines of choice (3). It went to the "improve error messages" PR by accident, if you'd like to take a look.

@yav yav closed this as completed in 273d8a3 Sep 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something not working correctly typechecker Issues related to type-checking Cryptol code.
Projects
None yet
Development

No branches or pull requests

2 participants