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

Improve counter-example printouts #659

Open
jldodds opened this issue Mar 24, 2020 · 2 comments
Open

Improve counter-example printouts #659

jldodds opened this issue Mar 24, 2020 · 2 comments
Labels
subsystem: cryptol-saw-core Issues related to Cryptol -> saw-core translation with cryptol-saw-core topics: error-handling Issues involving the way SAW responds to an error condition topics: error-messages Issues involving the messages SAW produces on error type: bug Issues reporting bugs or unexpected/unwanted behavior usability An issue that impedes efficient understanding and use
Milestone

Comments

@jldodds
Copy link
Contributor

jldodds commented Mar 24, 2020

Record names from cryptol are lost in SAW counterexamples, making it very hard to debug. For example:

prove: 1 unsolved subgoal(s)
 [_ = (34, False, 1, 0, (0, 1, 0), False, False, 1, False, False), 
  _ = (False, 1, False, False, 1, False)]
@langston-barrett langston-barrett added the topics: error-messages Issues involving the messages SAW produces on error label Mar 24, 2020
@atomb atomb added this to the 0.6 milestone Apr 3, 2020
@brianhuffman
Copy link
Contributor

brianhuffman commented Apr 7, 2020

The problem is a combination of two things: First, saw-core encodes cryptol records as tuples, and does not preserve record field names; the field names are only preserved in the cryptol type associated with the saw-core term. Second, the cryptol types are not included in the saw-core ProofGoal type, so the proof tactics that generate the counterexamples do not have the information they need to reconstruct the record field names.

To fix the problem, we will need to extend the ProofGoal type to include the cryptol types of all quantified variables. However, this is not enough: We also need a way to discover the cryptol type of any fresh_symbolic variable that may occur within the predicate. In order to do this, we will probably need to add a lookup table to the TopLevel monad to track the cryptol types of all fresh_symbolic variables.

@atomb atomb modified the milestones: 0.6, 0.7 Aug 6, 2020
@robdockins robdockins self-assigned this Oct 16, 2020
@atomb atomb modified the milestones: 0.7, 0.8 Dec 14, 2020
@atomb atomb modified the milestones: 0.8, 0.9 Apr 19, 2021
@robdockins robdockins removed their assignment Sep 10, 2021
@atomb atomb removed this from the 0.9 milestone Sep 22, 2021
@sauclovian-g
Copy link
Contributor

This is largely the same as #2119.

@sauclovian-g sauclovian-g added type: bug Issues reporting bugs or unexpected/unwanted behavior usability An issue that impedes efficient understanding and use topics: error-handling Issues involving the way SAW responds to an error condition subsystem: cryptol-saw-core Issues related to Cryptol -> saw-core translation with cryptol-saw-core labels Oct 29, 2024
@sauclovian-g sauclovian-g added this to the 2025T1 milestone Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
subsystem: cryptol-saw-core Issues related to Cryptol -> saw-core translation with cryptol-saw-core topics: error-handling Issues involving the way SAW responds to an error condition topics: error-messages Issues involving the messages SAW produces on error type: bug Issues reporting bugs or unexpected/unwanted behavior usability An issue that impedes efficient understanding and use
Projects
None yet
Development

No branches or pull requests

6 participants