-
Notifications
You must be signed in to change notification settings - Fork 123
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
issue702 #703
issue702 #703
Conversation
Have you tested this on the s2n example from the original post of #702? On Wednesday I made a patch that did the same thing as yours, but it wasn't sufficient to make that example work (which is why I didn't make a PR). Instead it revealed a different error message:
I expect that you'll find the same result with your branch. |
I didn't actually, oops. I suspect you're right. |
We might as well go ahead and merge this PR, because it does fix the issue covered by the regression test. But we shouldn't close #702 yet, as it seems that there might be a second bug hiding behind this first one. @robdockins, maybe you could edit your top post to remove the "fixes 702" bit, so github won't close the ticket when this PR is merged. |
I'd rather just fix the issue, I think. Do you have a pointer to the original spec causing the problem? I can't seem to find/reproduce. The nearest version I can find has the proof succeeding. |
a concrete value in `toExpr`. Fixes #702
…`FinType` This solves another manifestation of issue #702.
It looks like the counterexamples returned by
I would expect to have this instead:
|
Yeah, that's the result of ordering the fields when we construct the |
That sounds reasonable. I'll file a separate ticket for preserving the field order in type signatures and counterexamples after this PR is merged. |
Sort the fields of a record type before comparing with the fields in a concrete value in
toExpr
.Fixes #702