merl.hrl triggers erroneous compiler diagnostics

[nwalker]

Describe the bug After inclusion of merl.hrl, I'm getting unexpected and erroneous list of error diagnostics.

To Reproduce project/src/ttt.erl

-module(ttt).

-include_lib("syntax_tools/include/merl.hrl").

project/erlang_ls.yaml

otp_path: "/home/username/.asdf/installs/erlang/23.3.4.4/"
diagnostics:
  enabled: 
    - dialyzer
    - crossref
    - compiler
  disabled: 
    - elvis

Expected behavior diagnostics about unused include.

Actual behavior reported diagnostics:

  src/ttt.erl:
      1:1   error   Issue in included file (203): function pre_expand_case_clause/1 undefined ​Compiler
      1:1   error   Issue in included file (211): undefined macro 'Q/1' ​Compiler
      1:1   error   Issue in included file (232): function dummy_uses/1 undefined ​Compiler
      1:1   error   Issue in included file (250): undefined macro 'Q/2' ​Compiler
      1:1   error   Issue in included file (254): function make_orelse/1 undefined ​Compiler
      1:1   error   Issue in included file (259): undefined macro 'Q/2' ​Compiler
      1:1   error   Issue in included file (265): undefined macro 'Q/2' ​Compiler
      1:1   error   Issue in included file (39): can't find include file "merl.hrl" ​Compiler
      1:1   error   Issue in included file (49): function pre/1 undefined ​Compiler
      1:1   error   Issue in included file (50): function post/1 undefined ​Compiler
      1:1   error   Issue in included file (61): undefined macro 'Q/1' ​Compiler
      1:1   error   Issue in included file (86): undefined macro 'Q/1' ​Compiler
      1:1   warning Issue in included file (106): function expand_qquote/3 is unused ​Compiler
      1:1   warning Issue in included file (132): function expand_template/3 is unused ​Compiler
      1:1   warning Issue in included file (147): function eval_call/4 is unused ​Compiler
      1:1   warning Issue in included file (169): function pre_expand_match/3 is unused ​Compiler
      1:1   warning Issue in included file (176): function rewrite_pattern/2 is unused ​Compiler
      1:1   warning Issue in included file (187): function var_name/1 is unused ​Compiler
      1:1   warning Issue in included file (197): function var_to_tag/1 is unused ​Compiler
      1:1   warning Issue in included file (201): function pre_expand_case/3 is unused ​Compiler
      1:1   warning Issue in included file (223): function pre_expand_case_clause/4 is unused ​Compiler
      1:1   warning Issue in included file (253): function rewrite_guard/1 is unused ​Compiler
      1:1   warning Issue in included file (267): function is_inline_metavar/1 is unused ​Compiler
      1:1   warning Issue in included file (273): function is_erlang_var/1 is unused ​Compiler
      1:1   warning Issue in included file (278): function get_location/1 is unused ​Compiler
      1:1   warning Issue in included file (77): function case_guard/1 is unused ​Compiler
      1:1   warning Issue in included file (80): function case_body/2 is unused ​Compiler
      3:1   warning Unused file: merl.hrl ​UnusedIncludes

Turning compiler diagnostics off makes diagnostics disappear.

Context

• erlang_ls version (tag/sha): 0.18.0
• Editor used: Sublime Text 4
• LSP client used: Sublime-LSP v1.9.0

[KunaPrime]

can confirm that is also happening in neovim v.0.6.0-dev with native LSP client

[nwalker]

Well, I understood.

It was not diagnostics of my code, it was about merl_transform.erl.

All the chain looks like this:

• my code includes merl.hrl, which contains -compile([{parse_transform, merl_transform}]).
• erlang_ls attempt to check merl_transform.erl, which contains local include -include("merl.hrl").
• I have no include dirs specified for OTP installation, so that local include can't be resolved.
• merl_transform uses ?Q from merl.hrl at almost every function.
• erlang_ls reports bunch of errors 'cause of unresolved macro.

Errors disappeared after explicit declaration of OTP include dirs in erlang_ls.yaml.

The most confusing part was that erlang_ls follows parse transform directive but doesn't mention that anywhere in messages. Also I'm not sure it is mentioned in any docs, but I didn't recheck.

Feel free to close this issue.

[KunaPrime]

shouldn't the declaration of otp_path in erlang_ls.config be enough to correctly handle merl? I think this is still an issue.

[robertoaloi]

Hi @nwalker and thanks for reporting. I agree it's confusing. @KunaPrime Yes, OTP includes should be resolved automatically. Just Linking this ticket to the related #964 and #1047