Try to extract function argument names from signature, before defaulting to the first clause

[MarkoMin]

Describe the bug Some signature suggestions from stdlib are missing, e.g. lists:member/2. Is there a way I can add some of missing suggestions via new PR, or even better, is there a way to automate creating suggestions from source/edoc? Same thing occurs when using Erlang LS with NeoVim.

To Reproduce VSCode, erlang-ls extension v0.0.35 or erlang_ls 0.41.2 with NeoVim, type "lists:memb" and press enter.

Expected behavior Suggestions should be "Elem" and "List".

Actual behavior Actual suggestions are "Arg1" and "Arg2". Context

• erlang_ls version (tag/sha): 0.41.2
• Editor used: VSCode / NeoVim
• LSP client used: Not really sure what this means, VSCode extension erlang_ls and erlang_ls plugin on NeoVim

[robertoaloi]

Hi @MarkoMin,

The logic for extracting the variable names (which you can find here) is currently naive.

The parser looks at each function clause in isolation. If a function argument contains a variable (eg Elem), then the variable name is stored. If not, we default to a more basic ArgN name.

The lists:member/2 is a BIF, so if you look at its definition in the lists module you'll find:

member(_, _) ->
    erlang:nif_error(undef).

The parser finds the _, _ and then it defaults to Arg1 and Arg2.

In principle, a nicer signature could be extracted from the specs:

-spec member(Elem, List) -> boolean() when
      Elem :: T,
      List :: [T],
      T :: term().

But this would require some significant changes to the way the parser works. An easier solution would be to improve the auto-completion code to try and extract the argument names from the signature if available and, only if there's no signature, to report the arguments returned by the parser. This approach would have the nice side effect of providing more precise information to the user, since we currently extract the args from the first clause of a function and that may not be accurate if the user intended to use a different clause.

[robertoaloi]

Removing the bug label since this is not really due to a bug. It feels more like a (really nice) improvement in the Erlang LS behaviour.