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

Shrink Proofs/Obligations by default and deprecate option #218

Closed
wants to merge 13 commits into from

Conversation

mattam82
Copy link
Member

Fix bug in Shrink obligations with Program in the process.

@mattam82
Copy link
Member Author

@JasonGross
Copy link
Member

This flag should be (un)set in -compat 8.5 mode, right? (Should there be a test-suite file?)

@mattam82
Copy link
Member Author

Yes, good to remind me. I'm still unsure the implementation is right.

@mattam82 mattam82 force-pushed the shrinkobl branch 3 times, most recently from 7053a81 to 8f686e6 Compare June 27, 2016 14:32
Fix bug in Shrink obligations with Program in the process.
- Update doc in term.mli to reflect the fact that let-in's
  are part of what is returned by [decompose_lam_assum].
By default obligations defined by tactics are defined
transparently or opaque according to the Obligations Transparent flag,
except proofs of subset obligations which are treated
as opaque by default. When the user proves the obligation using
Qed or Defined, this information takes precedence, and only
when the obligation cannot be Qed'ed because it contains
references to a recursive function an error is raised
(this prevents the guardness checker error).
Shrinked obligations were not doings this correctly.
Forcing transparency due to fixpoint prototypes
takes precedence over the user preference.
Ensure correspondence between the term and type to shrink, so that Lets
are preserved when they are used relevantly in either of them.  This
avoids e.g. "simpl" in the shrinked hypotheses to reduce shrinking,
while maintaining unsimplified types in the type of the shrinked
obligations (for compatibility).
This maintains compatibility.
By invariant (we start with a term and its type), the abstraction's
types correspond.
@mattam82
Copy link
Member Author

Merged now, all the contribs pass.

@mattam82 mattam82 closed this Jun 27, 2016
jfehrle pushed a commit to jfehrle/coq that referenced this pull request Dec 19, 2022
218: [coq] Overlay for coq#10419 r=Janno a=ejgallego



Co-authored-by: Emilio Jesus Gallego Arias <e+git@x80.org>
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.

None yet

2 participants