-
Notifications
You must be signed in to change notification settings - Fork 632
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
[api] Refactor most of Decl_kinds
#10419
Conversation
Sadly this had to depend on the previous kind cleanup, last 4 commits are the relevant ones. |
cc: #10417 |
5c0729d
to
cbe628a
Compare
Ok, this may still need some thinking but IMHO the bulk is ready for review. This PR also answers a question posed by @maximedenes about |
We move the bulk of `Decl_kinds` to a better place [namely `interp/decls`] and refactor the use of this information quite a bit. The information seems to be used almost only for `Dumpglob`, so it certainly should end there to achieve a cleaner core. Note the previous commits, as well as the annotations regarding the dubious use of the "variable" data managed by the `Decls` file. IMO this needs more work, but this should be a good start.
The whole business of cst_kind is fishy tho, it seems to me that it should be removed from the libobject path.
They are clearly not at the same importance level, thus we use a named parameter and isolate the kinds as to allow further improvements and refactoring.
We remove two flags that were seldom used in favor of named parameters.
We can use logical kind for the same purpose, which is mainly dumpglob, so `goal_object_kind` was never matched against, making this transformation safe.
`declare_definition` didn't improve a lot the declare path and was used only once on interesting code. Also, it had many optional parameters. The declare path is critical enough as to care about a tidy API.
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.
I'm confused by the AlreadyDeclared name change, see comment.
val variable_opacity : variable -> bool | ||
|
||
(* Used in declare, very dubious *) | ||
val variable_context : variable -> Univ.ContextSet.t | ||
val variable_polymorphic : variable -> bool |
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.
These 2 can be removed: #10461.
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.
cool!
|
||
val add_variable_data : variable -> variable_data -> unit | ||
|
||
(* Not used *) | ||
val variable_path : variable -> DirPath.t |
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.
Why keep it then?
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.
I though we could address the refactoring of this module in its own PR.
We cleanup a few imports on Declare, and indeed we find a suspicious exception `AlreadyDeclared` present in `CErrors` where it should not be there. We move it to `Declare`, waiting for more investigation.
We should have this in the check target, but meanwhile we have to do manual housekeeping here.
Wrong label for exception fixed. |
Bench said: https://ci.inria.fr/coq/view/benchmarking/job/benchmark-part-of-the-branch/740/console
|
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.
Looking good
Reviewed-by: SkySkimmer Ack-by: herbelin
[coq] Overlay for coq/coq#10419
218: [coq] Overlay for coq/coq#10419 r=Janno a=ejgallego Co-authored-by: Emilio Jesus Gallego Arias <e+git@x80.org>
[coq] Overlay for coq/coq#10419
We move the bulk of
Decl_kinds
to a better place [namelyinterp/decls
] and refactor the use of this information quite a bit.The information seems to be used almost only for
Dumpglob
, so itcertainly should end there to achieve a cleaner core.
In particular the use of "variable" data stored in Decls seems very suspicious.
IMO this may need a bit more work, but this should be a good start, I wonder what people who know more about this
variable data
stuff can say.Overlays: