-
Notifications
You must be signed in to change notification settings - Fork 688
[auto] set use_metas_eagerly_in_conv_on_closed_terms = true #16293
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
Conversation
I don't think this solves the linked bug, because there are still discrepancies between (e)auto and simple (e)apply. |
At least, regarding the linked bug, the following works as expected: Inductive test : nat -> nat -> Prop :=
| test_intro n : test n (n + 1).
#[local] Hint Immediate test_intro : testdb_immediate.
#[local] Hint Resolve test_intro : testdb_resolve1.
#[local] Hint Resolve test_intro | 1 (test _ _) : testdb_resolve2.
#[local] Hint Extern 1 (test _ _) => simple apply test_intro; solve [ trivial ] : testdb_extern.
Goal test 0 1.
Proof.
Succeed (simple apply test_intro; solve [ trivial ]).
Succeed (solve [eauto with testdb_extern]).
Succeed (solve [eauto with testdb_resolve2]).
Succeed (solve [eauto with testdb_resolve1]).
Succeed (solve [eauto with testdb_immediate]).
Succeed (solve [eauto using test_intro]).
Abort. Also, the debug output of
Of course, there are still remaining (possibly justified) discrepancies between |
🏁 Bench results:
🐢 Top 25 slow downs
🐇 Top 25 speed ups
|
The bench shows that setting @RalfJung The rigorous goal management of What is also unfortunate, the It seems that other projects which have a less rigorous goal management break quite badly. |
Yeah, that's why we try to avoid these patterns -- less because of Coq changes and more because of other things that might change the goal.
The |
Yeah that pattern is super handy when using |
What I do is: |
It is very much not brief. Before:
After:
Also all these symbols make it a lot more work to type than //. |
The job library:ci-fiat_crypto_legacy has failed in allow failure mode |
@gares when I try to locally compile
EDIT: Also it requires a local opam |
Improves robustness in case of stronger (e)auto. This is in preparation of a change in Coq that will make auto and eauto stronger (rocq-prover/rocq#16293).
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
952dc3e
to
b84fb8a
Compare
Let's have a last bench, just in case. @coqbot bench |
🏁 Bench results:
🐢 Top 25 slow downs
🐇 Top 25 speed ups
|
The bench shows a few significant slow downs. Are they worth investigating? |
I did inspect the percentually biggest slowdowns. They come from the |
…s in simple apply) deduplicated auto and trivial code added regression tests, changelog entry
b84fb8a
to
4d69d32
Compare
@ppedrot Everything seems to be accounted for. I squashed and rebased on master for the merge. |
Erm, in that case squashing was probably not that good if we wanted to spot the difference of behaviour patch-by-patch. Well, I guess it doesn't matter now. @coqbot merge now |
Setting this flag in
auto
(andeauto
) makes the resolution be slightly closer tosimple (e)apply
.Also, this behavior is closer to
typeclasses eauto
.Fixes #16323
Fixes #16062
Currently,
debug auto
lies to you, stating thatsimple apply
failed.Also,
auto
may misleadingly report thatexact
failed #16323.The present PR makes auto more potent, sometimes breaking goal management after
tac; auto
.23e5b98
to66fd053
mit-plv/bedrock2#261