What is stopping us from doing https://github.com/coq/coq/issues/13394 in 8.16?
laziness
If we turn the warning into an error, will it just become an overlay writing exercise?
yes, conceptually trivial but annoying in practice
if you're brave enough to do it before the branch I'd support such an endeavour
(expect quite a bit of work between writing overlays and getting them merged)
We do however want to eventually introduce a default hint locality in the future right?
So I won't get rid of default_hint_locality but instead throw an error on its use?
make the warning AsError
Let's see what happens: https://github.com/coq/coq/pull/16004
Alright test-suite is the first causality, I'll work on that first.
There is also a warning for Hint Rewrite
should I make that an error too?
check what version it was made, if it's had a version as a warning then yes
That was 8.14 it seems
I will do their cleanup separately however just in case
The hard part is writing the overlays, fixing the bug on the Coq side is just a one-liner.
@Ali Caglayan do you need help to write the overlays?
I would welcome help on that
(I think that if we want this to happen for 8.16 we'd need a bit more manpower.)
I'm still messing around with the test-suite
I'm trying to come up with a killer regexp
there is the script that helps you tracking this
So far I had
^(?<!Global)(?<!Local )(?<!#[local] )(?<!#[global] )Hint(?! Rewrite)
but this doesn't catch everything
but then the problem is more the interaction with the build system
add -w -the-warning-name to get_coq_prog_args in the makefile
the test suite shouldn't care about this warning
(and add it to the _coqproject so editing works right)
@Gaëtan Gilbert do you have a bit of spare time to write some overlays ?
I count 4 such warnings, they're all part of 8.15 right?
-arg "-w +deprecated-hint-rewrite-without-locality"
-arg "-w +deprecated-hint-without-locality"
-arg "-w +deprecated-typeclasses-transparency-without-locality"
-arg "-w +deprecated-instance-without-locality"
The first is from 8.14
I don't know about the last 2
I think it is better to do one at a time for now
I don't believe hint rewrite is nearly as common
Doing the overlay for argosy rn
on bignums
argosy is vendoring coq-classes as a submodule so I submitted a patch there, hopefully we can bump that submodule later https://github.com/tchajed/coq-classes/pull/1
the overlays should be performed for all these warnings at once otherwise we'll lose time for the next change
(they will be all backwards compat)
Shall I make them all errors then?
we'll see for your PR, I think that now the important parts are the overlays
on geocoq
on mtac2
deprecated-typeclasses-transparency-without-locality is 8.15
ok
deprecated-instance-without-locality is 8.14 so I will add that too
(we don't have a ci on https://github.com/coq-community/bignums/pull/70? This looks a bit fragile given that it's a critical piece of software in the dependency graph of coq)
Only on push to master it seems https://github.com/coq-community/bignums/blob/059f1738ea3409f3d3dbf805d144878de3170fc7/.github/workflows/docker-action.yml#L11
@Karl Palmskog Do you remember why this is?
the closed PRs have CI
there is no problem with the CI configuration. It's GitHub that disables CI workflows after some number of days of inactivity
please do a force-push and you should get CI now
Huh weird
seems to have worked (cc @Pierre Roux btw)
I'm getting dynlink errors doing the overlay for mtac2 so giving up
for the record @Pierre-Marie Pédrot @Gaëtan Gilbert if you notice something like this again (missing CI for a coq-community project), you can go to the "Actions" tab, and there should be a warning there for "Docker CI". If you click on the warning, there is a button to re-enable CI
IINM, this is related to a repository having scheduled workflows.
on deriving
We should remove the scheduled workflow from bignums IMHO.
Ali Caglayan said:
deprecated-typeclasses-transparency-without-locality is 8.15
I don't think that make it a problem for making it a fatal warning in 8.16.
on category_theory
on color
on menhir
Can somebody add me to the INRIA gitlab?
@Ali Caglayan you need an account there, right? I can invite you if this is the case.
@Pierre-Marie Pédrot Yes, I need one.
Please send me you preferred email address for the account in a private message then.
(I seize the opportunity to complain about the use of the closed INRIA gitlab for CI devs.)
I am struggling to port math_classes since my crude find-and-replace seems to have changed the meaning of =
??
I would appreciate if somebody could take a look at it with me.
link?
I'll push in a sec
For some reason github got stuck forking
@Ali Caglayan you're not using the "official" porting script based on warning output?
@Gaëtan Gilbert https://github.com/Alizter/math-classes/tree/adapt-to-16004
Pierre-Marie Pédrot said:
Ali Caglayan you're not using the "official" porting script based on warning output?
No I though that was just a find and replace so I have been doing find and replace. :O
ah, but then the problem with find and replace is that you may screw up the section hints
That makes local instances global, indeed
(That = I looked at the diff)
Hopefully the overlays you already wrote are not behaviour-changing...
Hmm it should only be Hint (not Rewrite) inside a section with no locality that gets affected
oh dear maybe I was too zealous
Hint inside a section can't be global IIRC, but instances can.
Ah ok then its not so bad probably
I didn't change Instances too eagerly
well, it means that TC-heavy devs are probably broken
I'll go and mark them as potentially broken then
(I double-checked and indeed this only affects instances.)
This probably explains why math-classes didn't work
(Hint Rewrite is also immune to the problem because it doesn't allow global in a section either)
I can write the mathclasses patch if you want
Sure
I also couldn't finish verdi_raft
Probably for the same reason
Though all its deps are fine
verdi_raft just hangs for me, after a few changes
TC search maybe?
probably, I can't workout how to drop into coqide so I can't see it for myself
I do spot suspicious global flags for section instances in e.g. https://github.com/uwplse/verdi/pull/132/files
https://github.com/coq-community/math-classes/pull/111
Pierre-Marie Pédrot said:
Why did you disable the warnings?
it's actually activating it, but it was a missing git amend from myself, I've forced-pushed
Now that I think about it category_theory is also probably messed up
I didn't really question the huge amount of time it took to compile before
But now I think it might be tc going haywire
meh
in that case you should probably close your PRs that mention instances
FTR here's the script I used to port stuff: https://gist.github.com/ppedrot/3e0c7cbabd9042474c13c25dafefa677
you just set the warnings in the build system, redirect the stderr output to some file log
and call the script on that file
dafuq? math_classes has a CI that goes back to Coq 8.6
https://github.com/uwplse/cheerios/pull/10 looks fine right? I don't think any of those are in sections, just modules.
Ok I've closed most of the ones I suspect to be broken
I can't fork menhir because "I've reached my project limit"
interesting...
I also think I may have botched it anyway so I probably won't bother
I can port it then
I'll work on perf test
@Pierre-Marie Pédrot Shall I add that script to tools/ so that other users can use it?
I don't think so, it has been advertised already and it's pretty specific
How does menhirlib work w.r.t. versioning? We're picking a specific tag that is one year old, but there has been activity since.
In particular all the global warnings were fixed in master already
I guess menhir is good to have in the CI since it uses a lot of coq features. Why we are not tracking the master I don't know. I guess we can fast forward to a more recent commit.
I've written a PR for color: https://github.com/fblanqui/color/pull/42
perf tests seems to output warnings in stdout :/
Will the script work when other stuff is in there?
It doesn't really work for makefiles that call other makefiles
I give up on perf tests then
I managed to do VST that was easy, all of the work was already done
I don't know how to pass flags in Unimath
I haven't touched any of the fiat stuff except for rewriter
AFAICT they want to keep their backwards compatibility as much as possible, so I guess we will disable warnings instead
see https://github.com/mit-plv/rewriter/pull/42
I think that disabling warnings is just putting the dust under the rug.
It will bite us when we want to switch anyways.
I'm working on category_theory again trying to do it properly this time
Pierre-Marie Pédrot said:
I don't think so, it has been advertised already and it's pretty specific
IMHO it should be advertised again if we make these warnings fatal in 8.16. Especially now that it has been battle-tested.
Ali Caglayan said:
I guess menhir is good to have in the CI since it uses a lot of coq features. Why we are not tracking the master I don't know. I guess we can fast forward to a more recent commit.
This probably is because it used to be a non-Coq dependency for menhirlib. But now I think the two are in the same repo.
Pierre-Marie Pédrot said:
It will bite us when we want to switch anyways.
Especially true if we switch right after branching.
I'm not super fond of doing this change in 8.16 given the current state of affairs.
I'd rather try to fix the CI as much as possible so that the amount of work is limited when we really perform the warning > error switch.
I guess there is no rush to do it now, but at some point it had to be done.
Pierre-Marie Pédrot said:
I'm not super fond of doing this change in 8.16 given the current state of affairs.
What exactly do you mean by current state of affairs?
If it is about the CI then surely we can fix it?
The fact that there are some devs that make strong commitment on supporting pretty old Coq versions. This is reasonable (to some extent).
While striving to support 8.6 is probably not reasonable, 8.13 or so is not utterly crazy.
Also there are some devs which are probably nasty like fcl.
fcl?
Did you mean tcl?
fiat-crypto-legacy
OK so you want to give them more time to have a longer string of compatible versions?
Let's see what they say first, but I don't mind postponing the change to one more version.
How bad do you think bedrock2 will be?
I might start it...
It's looking messy :(
FWIW I'm on unimath
it was surprisingly easy, they basically declare no hints except in their prelude
category theory done
@Jason Gross You say for rewriter that you would rather have your hint localities silently export and fix it when this happens, what is wrong with dropping support for older versions and fixing it properly now?
@Ali Caglayan I don't plan to drop support for older versions when the default behavior changes, I plan to fix it in a way that is backwards compatible.
Will you wait until we switch the locality and everything breaks to fix it or fix it before?
In that case, your fixes will be doing the job of our overlays.
It looks like this won't make it to 8.16 anyway, so there is around 6 months to fix everything give or take
Is this the same for fiat_crypto etc. too?
I'm inclined to wait until there is at least an option to change the default locality, so that there's no chance of regression (because the option will be a no-op on older versions of Coq and CI will test newer versions of Coq). (Speaking of which, how do you / the devs feel about adding a deprecated option to change default locality?) Once this option exists, I can make the change (for rewriter, bbv, f-c-l, fiat-crypto, and to some extent coqutil; for bedrock2 and rupicola we drop version support much more quickly).
there's no option plan is there?
The option plan is literally already there.
@Pierre-Marie Pédrot You mean that there is currently an option to do this in Coq? What is it called, I cannot find it.
@Jason Gross when you say “the option will be a no-op on older versions of Coq”, you must mean “we will not pass the option to older Coq versions” I suppose (say, you’ll autogenerate _CoqProject
through conditional compilation)? Otherwise I’m not sure adding the option is technically possible.
Whether devs are willing to provide it is another matter. Could you enlighten us why you still support Coq 8.6? Is that because the cryptography code from fiat-crypto has active non-Coq users on older distributions?
In that case, I wonder if the code generation should be done upstream and the pre-generated C should be distributed for older distros, but there might be complexities there too.
Paolo Giarrusso said:
Jason Gross when you say “the option will be a no-op on older versions of Coq”, you must mean “we will not pass the option to older Coq versions” I suppose (say, you’ll autogenerate
_CoqProject
through conditional compilation)? Otherwise I’m not sure adding the option is technically possible.
If I do
Set Option "foo".
it just throws a warning.
Let me lay out my plan all in one place:
Fiat Crypto supports the latest Ubuntu LTS and Debian Stable. I think these versions don't support Global Hint Rewrite
, but if they do I'm happy to explicitly annotate. (I would like to eventually switch to #[export]
, once the Ubuntu LTS / Debian Stable versions of Coq support it.). Part of the sales pitch of fiat-crypto is that users can generate code for new primes, so I'd prefer to maintain out-of-the-box compatibly with these distributions.
Fiat Crypto Legacy supports back to 8.7. There is no pressing reason to keep this support in place, as indeed there are no users of f-c-l other than Coq's CI and anyone that is trying to do archeology on the code from our 2019 paper. However, I'd like to keep this support in place as long as it doesn't incur too much burden.
My plan, for Fiat Crypto Legacy, bbv, and for Fiat Crypto and the rewriter if necessary, is:
Exports
module that re-exports the Exports
modules of all files that it requires, and stick the necessary hints in these modules. However, as I'd like to eventually move to #[export]
behavior, I will aim to be less sledgehammery about following the export discipline. Since no file will rely on default-export hints not being available via Require, and all files will work with default-export behavior, this should be backwards compatible.Set Foo
is a no-op for unrecognized Foo
) to enforce that the CI checks compatibility with the upcoming default behaviorhttps://packages.ubuntu.com/jammy/coq is 8.15.0, but https://packages.debian.org/bullseye/coq uses 8.12.0 and https://wiki.debian.org/DebianReleases implies the next release is expected around (late) next year, so after Coq 8.18.
I now suspect the option might be Set Loose Hint Behavior "Strict"
, which was available in 8.12! But it seems to affect only Hint Resolve
and Instance
: https://coq.inria.fr/distrib/V8.12.2/refman/proof-engine/tactics.html#coq:opt.loose-hint-behavior.
but as defined, that seems to affect even hints that are explicitly marked #[global]
, instead of just unannotated hints?
FTR @Jason Gross, your strategy of using an option because unknown options just trigger a warning would also work with attributes as long as you are willing to make Coq 8.11 a hard requirement for all your projects (which seems reasonable given the versions available in Ubuntu LTS and Debian reported by Paolo just above): https://github.com/coq/coq/pull/10997
This warning is fatal by default, but you can locally disable it since it's a warning.
My point was exactly what Théo said, i.e. unset unknown attribute fatality.
on bedrock2
I've updated the list and it has grown
Incidentally, it seems the implementation of this warning makes elaboration of attributes depend on the logical environment, doesn't it?
I hit it in my parsing / execution separation branch
(it is because the only way to know if a section is open currently seems to be by asking the kernel, but this warning wants to do it more or less at parsing time, if you consider attribute elaboration being part of parsing)
Can we not simply lex the file and check if a section is open? I don't know about Undo tho.
Undo
is only about tactics IIRC
I believe Lib
used to have the right information about sections, but it was moved to the kernel
@Pierre-Marie Pédrot I see that there has been a lot of progress recently. What are we waiting for with fiat parsers and engine bench?
I've just written an overlay for fiat-parsers today, but it's breaking backwards compat so it'll need some tweak. Same problem for engine-bench, @Jason Gross wants it to be backwards compatible with quite old versions.
Last updated: Dec 06 2023 at 14:01 UTC