erlang
Add erl_anno:set_end_location/2
See the discussion in https://github.com/erlang/otp/pull/8945#discussion_r1806260645.
Currently erl_anno:end_location(Anno) is inferred from location and text (if present). However, this means that in order to store a location range, we always need to store the whole text. This allows setting end_location of Anno directly.
With this change erl_anno:end_location(Anno) will first look for end_location set directly and then fallback to the inference if applicable.
CT Test Results
2 files 96 suites 1h 7m 1s :stopwatch: 2 161 tests 2 113 :white_check_mark: 48 :zzz: 0 :x: 2 520 runs 2 470 :white_check_mark: 50 :zzz: 0 :x:
Results for commit fa58d2c9.
:recycle: This comment has been updated with latest results.
To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.
See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.
Artifacts
// Erlang/OTP Github Action Bot
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
FYI #3026 also suggests adding this and has some other additions. I'll leave the decided on what to do to @bjorng and @jhogberg.
It is not clear to me from the discussion in #8945 who would actually call erl_anno:set_end_location/2? The scanner? A tool such as an editor?
So what I'm asking whether this new function would be useful without also updating the scanner and/or parser.
@jhogberg and I looked at #3026 and thought it would be useful to implement something like that to be able to provide better compiler messages and warnings, but we might want to implement in a slightly different way (with less heuristics). However, it is unlikely that will happen before Erlang/OTP 29.
This would not be used by the scanner but it could be used by the parser. The issue today is that we only keep token information from the scanner, but if we want to know the whole range of a function clause, we can't store that today. By adding this, we would allow the parser to annotate the end location (based on the . or ; or end tokens) when building the clause abstract format. Elixir would also use this to store similar information in the Docs chunk (that today uses erl_anno).
