Add erl_anno:set_end_location/2

[jonatanklosko]

See the discussion in #8945 (comment).

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.

[github-actions]

CT Test Results

    2 files     96 suites   1h 7m 1s ⏱️
2 161 tests 2 113 ✅ 48 💤 0 ❌
2 520 runs  2 470 ✅ 50 💤 0 ❌

Results for commit fa58d2c.

♻️ 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

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

[jonatanklosko]

The end_location is a bit tricky in the current tests setup, because it's both primary and secondary part of anno. In order to accommodate this, here we need to infer the value here (similarly to the clause for line above). Duplicating the whole text scan logic from the actual implementation sounds weird, so I call the inference directly.

I am happy to revise the tests, if another approach is preferable :)

[gomoripeti]

great addition

[garazdawi]

FYI #3026 also suggests adding this and has some other additions. I'll leave the decided on what to do to @bjorng and @jhogberg.

[bjorng]

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.

[josevalim]

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).

[bjorng]

This looks good to me. Please squash the commits and force-push.

[jonatanklosko]

Done!