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
mattam82
left a comment
There was a problem hiding this comment.
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.mlclose 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_entryphase out ofclosed_proofandclose_future_proof.Depends on: