-
Notifications
You must be signed in to change notification settings - Fork 667
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
Locating identifiers in tactics (including ltac2, ssr) #13103
Conversation
ba24eb9
to
d26c3f7
Compare
The job library:ci-fiat_crypto_legacy has failed in allow failure mode |
d26c3f7
to
2361efa
Compare
The job library:ci-fiat_crypto_legacy has failed in allow failure mode |
The PR removed |
What did they do? |
FTR, I really don't like this PR. It is adding a lot of debugging information in the wrong place, namely the toplevel value of something that is not an AST, thus polluting the runtime with a lot of irrelevant data. Most of the time one does not even want to know about this debug data, especially when it comes from another file, e.g. when declaring toplevel tactics in some general purpose library. Maybe for Ltac1 it's a necessity because there is no clear separation between idents and other similarly shaped data, but I firmly believe that for Ltac2 this should be handled at the level of functions via backtraces, and definitely not at the level of data for such generic purpose types (user-facing ASTs are another matter, though). As such, except if there is a very good argument in favour of this PR I'd prefer a statu quo. |
let s, id' = interp_wit wit_ident ist gl id in | ||
s, Id (SsrHyp (loc, id')) | ||
let s, id' = interp_wit wit_identref ist gl (CAst.make ?loc id) in | ||
s, Id (SsrHyp (loc, id'.CAst.v)) |
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 guess this diff hunk supports @ppedrot thesis. Here the loc is already in the AST, the copy in the ident is just getting in the way. It would feel more natural to pass loc to interp_wit frankly.
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 would say that it is expected that interp_wit
takes a loc since it goes from user-facing syntax to "abstract" syntax (the first line of the diff). What is more questionable (and what @ppedrot questions, afaiu) is that interp_wit
continues to return the loc (the second line of the diff).
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.
What I meant is that if you don't put the loc in the ident in the fist place, then interp_wit is not going to return it, you can still pass the loc as you pass ist and gl if you need to
I don't like either to pollute a library part ( For instance, would something like following be acceptable for you: the tactic in In any case, I'm ok with the statu quo (the error messages are already designed on the assumption that they do not know the loc and thus repeat the name of the identifier), but I'd really be interested that the underlying issue is not ignored. The PR has however more than just changing
instead of
Is this OK? |
Nah, that's also runtime polluting.
More precisely, only attaching such data when inside a script. This could be done by inserting locating wrappers inside the AST in non-strict mode, for instance. |
Do you mean that you have a solution to avoid loc in
My imagination is unfortunately not big enough to visualize what you have in mind... |
2361efa
to
41a1c32
Compare
In passing, we use the location also for intros, etc.
41a1c32
to
5facd93
Compare
The job library:ci-fiat_crypto_legacy has failed in allow failure mode |
If I call e.g. |
My understanding is that this is not ready and some discussion (esp with @ppedrot) has to happen to devise the design |
The "needs: rebase" label was set more than 30 days ago. If the PR is not rebased in 30 days, it will be automatically closed. |
This PR was not rebased after 30 days despite the warning, it is now closed. |
Kind: "cleanup"
This is part of the project started in #11842.
We use located identifiers in tactics in anticipation of identifying
Prim.identref
andPrim.ident
, with the latter eventually taking a location by default and the former being eventually deprecated.Tactics
intro_move
,rename_hyp
,instantiate_by_name
,fix
/cofix
,destruct
, ... now take a located identifier. This is a compromise in the sense that internal calls to these tactics need to add a dummy loc just to comply to the extended API. On the other side, having the location at hand in error messages is desirable when the call directly comes from the user (for instance,intros H
may now hightlightH
, though there are still some issues, as indicated in #13100, which make thatintro H
does not highlight errors onH
).The first commit is shared with #13102 (it does not matter which PR comes first).
The four next commits are about tactics but do not concern interpretation, thus, in some sense, they could have been alternatively in #13100 (for
HypLocation
) or #13102 (forDerive Inversion
or Ltac definitions).The last six commits (7th to 12th) rely on the support for located identifiers in
ARGUMENT EXTEND
andTACTIC EXTEND
, which is provided by the 6th commit.In
ssrparser
, some harmonization could be done, e.g. usingId.t CAst.t
in some places rather thanId.t Loc.located
(e.g. inSsrHyp
). I can do it if there is a will to, or the work can also be shared, if this is what is preferred.In Ltac2, I did not change the parsing rules so that they possibly pass located identifiers to tactics. I may try to do it, if there is a demand.