-
Notifications
You must be signed in to change notification settings - Fork 237
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
A fix in the core typechecker #3004
Conversation
*) | ||
|
||
[@expect_failure] | ||
(* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is interesting. The example that was showing failing smt proofs, now works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weird! I noticed the same thing in a completely separate branch, so maybe some dependency got updated? In fact even master does not pass (local) ci for me right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There seems to be a difference between running with --query_stats and without. CI will pass using that flag (this definition will fail as expected). You might need to revert this change to get a green. I'll look to see what causes this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Solved in #3010
I have an everest green, merging. |
Adding a missing check for expected effect in the case when the expected type is not set.
The fix failed some examples, where the core client wanted a total effect on non-informative types, but core computed a ghost effect (and the cases passed due to the missing check).
To fix those cases, the PR also adds eager promotion so that it computes a total effect in such cases.
The PR also contains a small optimization in inserting hide/reveal coercions. If the expression is
reveal e
(resp.hide e
), and the context expects an erased (resp. non-erased) type, then instead of making the coercion returnhide (reveal e)
(resp.reveal (hide e)
, we just returne
.The last optimization resulted in two failures, one each in
Steel.ST.Array
andSteel.ST.HigherArray
. Since the coerced expression is a little different, tworewrite
calls in the libraries (one in each file) had to be tweaked. In general, smt attribute saves us, but these cases were where the coercion was happening in the first argument ofpts_to
(see FStarLang/steel#63).