This uniformly adds a location to identifiers at parsing time and it seems basically ready for a (trivial) review.

The dpdgraph and macosx CI errors are unrelated.

Does this pull request only need a rebase or is there more to it? There have been no changes since 8.13.

@silene I don't agree with the idea that adding locations to runtime values is a good thing. I've already argued several times offline that it did not make sense, since locations are only meaningful for code / closures that are going to be executed in debug mode, not for stuff which is already computed.

Somehow, this was related to #13103 about which no conclusion was found with @ppedrot (basically, the unresolved question is: how deep is it morally justified to propagate a location so as to locate error messages vs polluting a code which per se is conceptually unrelated to parsing).

But if @ppedrot agrees, I can just do the change he suggests and have the current PR merged.

since locations are only meaningful for code / closures that are going to be executed in debug mode, not for stuff which is already computed.

What is not clear though is whether you agree that when a location is meaningful (at least in strict mode), it is useful for a user to have it?

@herbelin I think I managed once to convince you that it did not make sense to attach locations to runtime values, but that instead it should be attached to the code manipulating them. Since it looks like either I have dreamt or you have forgotten about it, let me rehash the arguments.

Assume you have tactic mytac that takes an identifier and may fail, e.g. if the identifier does not exist in the context. For the sake of the argument, assume that all the identifiers we will pass it below trigger a failure.

Consider the following situations:

mytac ident:(H).

let H := ident:(H) in mytac H.

let H := concat ident:(foo) ident:(bar) in mytac H.

Ltac id := ident:(H).
...
mytac id.

Ltac id := ident:(H). (* in another file *)
...
mytac id.

Now, what do you underline? If you believe locations are attached to values, you don't have much choice and a best effort solution means that you won't underline anything, except for case 1 and maybe 2. If you tell me that one instance of these should underline the syntactic argument of mytac, you're confessing that you secretly believe that locations are not attached to values.

I personally believe that in all these cases we should underline the syntactic argument, because this is the only thing that makes sense in general. The worst part of this observation is that it is actually easy to do (in Tacinterp). But this PR does not make any progress on that front. Worse it is randomly polluting the runtime with irrelevant data.

@ppedrot: I think you meant #13100 and #13103 in your last comment. This PR (#13102) is about the use of ident in vernac rules and I would suspect that it is fine for you (up to replacing val wit_identref : lident uniform_genarg_type with val wit_identref : (lident, lident, Id.t) genarg_type).

About #13100 and #13103, there is no urgency for discussing them right now, but we should eventually separate the issues. The question of locating evaluated tactic expressions is taking all the place in the discussion while 1) I agree with the issue that you're raising 2) this was not the primary objective of this set of PRs and I'd suspect that you are not opposed to the primary objective.

1. The primary goal was to make uniform the use of ident, identref, name, lname in grammars. At some point of the discussion, there was some conclusion that we could simply have a single basic entry ident (as well as name) to be located by default.

   Is this primary objective worth to you?

2. Then, while working at this objective, I observed that various errors/warnings in the code could take benefit of locations in their message, and that was an opportunity to localize more precisely these error messages.

   Do you agree with the principle that it is (in general, when the location is relevant) good to have precisely located error messages (and thus to carry the location to the point where this error messages are raised)? [In particular, I share your concern of "polluting". So, maybe can we find other ways to attach locations to error messages than by propagating explicitly locations to the error messages, as was done for exceptions??]

3. This PR is about locating a few places in vernac commands.

   Do you agree with the changes in error messages made in this PR?

About #13100 and #13103 and your examples, I can imagine different localization strategies but why not locating the syntactic argument (ident(H), H or id respectively then), that's fine to me. You say we can do it easily in tacinterp.ml, but I fail to see how. So about #13100 and #13103, I need help on what you have in mind exactly to pass the syntactic location to the error messages.

Now, if the question of locating errors in Ltac is too complex, it might be wise to postpone it so that it does not block the original goal (1.). It makes me sad, because it is a renouncement to address an interesting issue without even a vision on how we could resolve it in the future, but that could also be reasonable (in which case I would reduce #13100 and #13103 to only their grammar part).

Indeed, I got a bit carried over. This PR is precisely the fragment of the original PR I completely agree with (modulo code nits from the review).

To reassess my position:

Is this primary objective worth to you?

Yes.

it is (in general, when the location is relevant) good to have precisely located error

All the problem with this question is concentrated in the proviso. Except for vernacular commands, the relevance of the location quickly vanishes when used in a language that lets you manipulate values, be it Ltac1 or Ltac2.

Do you agree with the changes in error messages made in this PR?

Yes, sorry, this PR can go in. (If you can fix the nits that would be better but my quota of ranting was exhausted with this one.)

@ppedrot: thanks for your answer!

I changed the glob of identref to Id.t.

While at it, I added a dependency on #14442 which adds the infrastructure to locate constants in extraction error (the previous version of the PR was using the location at a useless place actually).

@silene: I postponed to 8.15. It is better if the whole set of PRs go altogether.