Skip to content

Fix cover diagnostic messages to distinguish from assertions#413

Open
MikaelMayer wants to merge 15 commits intomainfrom
fix-cover-diagnostic-messages
Open

Fix cover diagnostic messages to distinguish from assertions#413
MikaelMayer wants to merge 15 commits intomainfrom
fix-cover-diagnostic-messages

Conversation

@MikaelMayer
Copy link
Contributor

Summary

The toDiagnosticModel function was not cover-aware - it always reported "assertion does not hold" even for cover statement failures.

Changes

  • For .fail results: report "cover property is not satisfiable" for cover statements, "assertion does not hold" for asserts
  • For .unknown results on cover statements: only report diagnostic in debug mode (verbosity > normal), since it's informational rather than an error
  • For .unknown results on asserts: always report "assertion could not be proved"

Testing

The change affects diagnostic message generation only.

@MikaelMayer MikaelMayer marked this pull request as ready for review February 12, 2026 19:33
@MikaelMayer MikaelMayer requested a review from a team as a code owner February 12, 2026 19:33
- Test that cover failures produce 'cover property is not satisfiable'
- Test that assert failures produce 'assertion does not hold'
- Test that passing statements produce no diagnostics
- Extract only messages to avoid unstable byteIdx in test expectations
Tests that same expression (x > 0) produces no diagnostic for cover (satisfiable) but produces 'assertion could not be proved' for assert (unprovable)
Tests that same expression (x > 0) produces no diagnostic for cover (satisfiable) but produces 'assertion could not be proved' for assert (unprovable)
some {
fileRange := default
message := s!"Internal error: diagnostics without position! Metadata value for fileRange key was not a fileRange. obligation label: {repr vcr.obligation.label}"
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder how the line numbers in CorePrelude.lean were recorded - do they have fileRange metadata?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The line numbers are the lean's line numbers.

MikaelMayer and others added 4 commits February 16, 2026 13:44
- Update verify function calls to match new signature (solver now in Options)
- Use z3 instead of cvc5 since cvc5 is not available in this environment
- Update expected message for third test (assertion fails, not just unprovable)
atomb
atomb previously approved these changes Feb 16, 2026
Copy link
Contributor

@atomb atomb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's one thing that could be simplified, but it's not blocking.

Use the existing Imperative.getFileRange helper function instead of
manually finding and matching the fileRange element from metadata.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants