-
Notifications
You must be signed in to change notification settings - Fork 685
Factorization of close_proof and close_future_proof in declare.ml #19320
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
Factorization of close_proof and close_future_proof in declare.ml #19320
Conversation
ccb07f8
to
d41458b
Compare
d41458b
to
066120b
Compare
066120b
to
2243a9d
Compare
29a6295
to
2243a9d
Compare
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.
The factorization looks good to me, and this does not change the interface, so unless this breaks CI, I think we can merge. Can you explain why you did the change in vernacstate.ml though?
2243a9d
to
d780de7
Compare
d780de7
to
8842018
Compare
@coqbot run full ci |
8842018
to
41c02eb
Compare
I rebased wrt #19545 but note that part of the job of the newly-profiled |
41c02eb
to
c50c721
Compare
base+async failure looks real |
…er to declare_entry.
…are_entry. This will allow to let declare_mutual_definition depend on it. Note: The converse would be more difficult because declare_possibly_mutual_definitions works from the beginning on Future computations while declare_mutual_definition currently move to a Future computation only after some time.
c50c721
to
f2ac5c3
Compare
Should be fixed (was not the correct type to associate to the initial uctx). I realized in passing that base+async seems to be the only regression test about delayed "future" proofs (besides test-suite/stm), good to know. |
@coqbot merge now |
This PR starts moving the universe treatment in
declare.ml
close to the final declaration of constant, as in rocq-prover/rfcs#89.At this stage, it introduces a new type distinguishing between future-based proofs and non-future-based proofs, then moves the
closed_proof_output
->pproof_entry
phase out ofclosed_proof
andclose_future_proof
.Depends on: