(MatchError) no match of right hand side value in main module of an application

[ivanhercaz]

Hi!

First, thank you for your work on NextLS and the elixir-tools ecosystem.

I am having a strange issue that I don't get to solve it.

Environment

• OS: macOS 15.1.1 24B91 arm64
• CPU: Apple M1 Pro
• Erlang/OTP 27 [erts-15.2]
• Elixir 1.18.1 (compiled with Erlang/OTP 27)
• Visual Studio Code 1.96.2

Both, Erlang/OTP and Elixir, installed using Homebrew.

Issue

I have a simple Phoenix app named :api, so the main modules are Api and ApiWeb. In the case of the first one, once I save one file for the first time (let's say change something in device_json.ex as shown in the stacktrace), there is a MatchError in api.ex file. This file is an empty module:

defmodule Api do
  @moduledoc """
  Api keeps...
  """
end

The MatchError appears in the same defmodule and shows the next stacktrace:

** (MatchError) no match of right hand side value: {:debug_info_v1, :elixir_erl, {:elixir_v1, %{attributes: [], module: Api, file: "/Users/ivan/dev/PROJECT_DIR/PROJECT_APP_DIR/api/lib/api.ex", deprecated: [], unreachable: [], anno: {1, 1}, struct: nil, after_verify: [], defines_behaviour: false, definitions: [], signatures: %{}, impls: [], compile_opts: [], relative_file: "lib/api.ex"}, []}}
    /Users/ivan/Library/Application Support/.burrito/next_ls_erts-15.0_0.23.2/lib/next_ls-0.23.2/priv/monkey/_next_ls_private_compiler.ex:196: NextLSPrivate.Tracer.trace/2
    (elixir 1.18.0) src/elixir_env.erl:30: :elixir_env."-trace/2-lc$^0/1-0-"/3
    (elixir 1.18.0) src/elixir_env.erl:30: :elixir_env.trace/2
    (elixir 1.18.0) lib/kernel/parallel_compiler.ex:443: anonymous fn/5 in Kernel.ParallelCompiler.spawn_workers/8

Another important detail is that Visual Studio Code shows a notification saying "Failed to format lib/api_web/controllers/device_json.ex". If I hover any code, doesn't show anything unless there is an error or a warning marked and if I don't remember wrong, it should show the docs for the function you hover.

To be honest, I have not idea of what may be happening in this case. I keep thinking in this issue and if I discover something more I will include in this issue. Of course, feel free to change the title of the issue if you have one more suitable 😅 .

Full stacktrace

This stacktrace shows all the process done after change and save device_json.ex, of course, as I mentioned before, it happens changing and saving any file, it is not an specific issue with this file.

[Info  - 11:46:07] [Next LS] Compiled api!
[Warn  - 11:46:15] [Next LS] Failed to format lib/api_web/controllers/device_json.ex
[Info  - 11:46:15] [Next LS] Compiling 14 files (.ex)
[Info  - 11:46:15] [Next LS]     warning: variable "changeset" is unused (if the variable is not meant to be used, prefix it with an underscore)
    \x{2502}
  5 \x{2502}   def error(%{changeset: changeset}) do
    \x{2502}                          ~~~~~~~~~
    \x{2502}
    \x{2514}\x{2500} lib/api_web/controllers/changeset_json.ex:5:26: ApiWeb.ChangesetJSON.error/1
[Info  - 11:46:15] [Next LS]     warning: variable "error" is unused (if the variable is not meant to be used, prefix it with an underscore)
    \x{2502}
 18 \x{2502}   def show(%{model: model, error: error}) do
    \x{2502}                                   ~~~~~
    \x{2502}
    \x{2514}\x{2500} lib/api_web/controllers/device_json.ex:18:35: ApiWeb.DeviceJSON.show/1
[Info  - 11:46:15] [Next LS] 
== Compilation error in file lib/api.ex ==
** (MatchError) no match of right hand side value: {:debug_info_v1, :elixir_erl, {:elixir_v1, %{attributes: [], module: Api, file: "/Users/ivan/dev/PROJECT_DIR/PROJECT_APP_DIR/api/lib/api.ex", deprecated: [], unreachable: [], anno: {1, 1}, struct: nil, after_verify: [], defines_behaviour: false, definitions: [], signatures: %{}, impls: [], compile_opts: [], relative_file: "lib/api.ex"}, []}}
    /Users/ivan/Library/Application Support/.burrito/next_ls_erts-15.0_0.23.2/lib/next_ls-0.23.2/priv/monkey/_next_ls_private_compiler.ex:196: NextLSPrivate.Tracer.trace/2
    (elixir 1.18.0) src/elixir_env.erl:30: :elixir_env."-trace/2-lc$^0/1-0-"/3
    (elixir 1.18.0) src/elixir_env.erl:30: :elixir_env.trace/2
    (elixir 1.18.0) lib/kernel/parallel_compiler.ex:443: anonymous fn/5 in Kernel.ParallelCompiler.spawn_workers/8
[Info  - 11:46:15] [Next LS] Compiled api!

[alexslade]

Pretty much exactly this same happening for me on a different project. Currently debugging it, I'll share if I find anything interesting.

[mhanberg]

I believe this is due to a change in debug info representation in 1.18.

@jonatanklosko I think there is a new anno field that replaces the line field in the debug info.

Is this a regression or private api that I should fix?

The offending code looks like this

    {:ok, {_, [{~c"Dbgi", bin}]}} = :beam_lib.chunks(bytecode, [~c"Dbgi"])

    {:debug_info_v1, _, {_, %{line: line, struct: struct}, _}} = :erlang.binary_to_term(bin)

[ivanhercaz]

If there is something in which I can help for debugging, don't hesitate to ask me! Thank you both for your fast response!

[jonatanklosko]

@mhanberg yeah it was intentional, now there is :anno field and you can do erl_anno:line(anno).

@josevalim I believe we looked around if it was used, I guess we missed this one?

[mhanberg]

I can just work around it, wanted confirmation and direction on how to get the line from the anno structure.

Thanks!

[mhanberg]

@jonatanklosko related, also seeing now that the struct definition from a module (fetched via Module.get_definition(mod, {name, arity}) is reporting the line number as 0.

Previously it was being reported as the line of the call to defstruct

[josevalim]

The code currently says:

    # We attach the line: 0 to struct functions because we don't want
    # the generated callbacks to count towards code coverage and metrics,
    # especially since they are often expanded at compile-time.
    functions =
      quote line: 0, unquote: false do
        def __struct__(), do: unquote(escaped_struct)
        def __struct__(unquote(kv)), do: unquote(body)
      end

So it was added to improve the usage of tools like --cover. I guess the best way to get the definition of a struct today is by using compilation tracers and intercepting the expansion of Kernel.defstruct macro. Although I am also realizing that this completely messes up go to definition in ExDoc. I will investigate further.

[josevalim]

The line will be fixed in v1.18.2.

[mhanberg]

Thanks @josevalim!

[ivanhercaz]

Thank you very much to everyone for working on this issue!