Parser fails on ?STACKTRACE macro

[plux]

Describe the bug
EEP-47 added new syntax to retrieve stacktraces in try/catch and thus deprecated the use of erlang:get_stacktrace().
To handle backwards compatibility the use of a macro became widespread in the Erlang community:

-ifdef(PATTERN_STACK).
-define(STACKTRACE(Type, Reason, Stacktrace), Type:Reason:Stacktrace ->).
-else.
-define(STACKTRACE(Type, Reason, Stacktrace), Type:Reason -> Stacktrace = erlang:get_stacktrace(), ).
-endif.

Which could be used like this:

try
  do_stuff(),
catch ?STACKTRACE(What, Rsn, St)
    handle_error(What, Rsn, St)
end.

However unfortunately els_parser (els_dodger?) fails to parse this syntax and this means that POIs in a function which uses the ?STACKTRACE macro won't be registered.

To Reproduce
Add a module such as this to a project

-module(catch_stacktrace).
-export([a/0]).
-define(STACKTRACE(Type, Reason, Stacktrace), Type:Reason:Stacktrace ->).

a() ->
  try
    b()
  catch ?STACKTRACE(What, Rsn, St)
    {error, {What, Rsn, St}}
  end.

b() ->
  ok.

Place pointer on call to b() inside a() and try to goto definition.

Expected behavior
Pointer jumps to definition of b().

Actual behavior
Editor tells me "No definitions found for: b"

Context

• erlang_ls version (tag/sha): 0.15.0
• Editor used: Emacs
• LSP client used: lsp-mode

[robertoaloi]

Hi @plux

we just merged #979, which switches to the erl_fmt parser. Could you please check if this is still an issue with the latest version from main?

[plux]

Yes this is still an issue even with erlfmt.

[robertoaloi]

FYI @gomoripeti @michalmuskala

[gomoripeti]

hi @plux
I haven't seen this solution yet, what I've seen is a pair of two, more well-formed macros that should be supported by both els_dodger and erlfmt_parse.
#852
eg:
devinus/poolboy@5d40cc5

ofc the above is valid, compiling erlang code, so I'm not sure how far we can/should go in handling exotic macros

[michalmuskala]

Yes, the erlfmt parser does not handle this either. In general we only handle lexical macros - i.e. macros that are complete lexical elements. In particular in here the -> inside the macro is completely detached and the catch inside of try is later missing it.

Supporting things like that with the current approach to parsing either in els_dodget, but also in erlfmt, seems generally extremely complex if not outright impossible.

[robertoaloi]

All right, marking this as a "won't fix" for the time being, but we can keep this for reference. Should things change we can re-open the issue.