Difficult to rationalize cyclic dependency checks.

[ityonemo]

Elixir and Erlang/OTP versions

Erlang/OTP 27 [erts-15.2.7] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit:ns]

Elixir 1.18.3 (compiled with Erlang/OTP 27)

Operating system

linux (but this is a compiler issue)

Current behavior

a.ex:

defmodule A do
  defmacro __using__(_), do: :ok

  def fun(%B{}), do: :ok
end

b.ex:

defmodule B do
  use A
  defstruct []
end

Causes a cylic dependency error. Error message:

== Compilation error in file lib/b.ex ==
** (CompileError) deadlocked waiting on module A
    (elixir 1.18.3) src/elixir_dispatch.erl:261: :elixir_dispatch.expand_quoted/7

== Compilation error in file lib/a.ex ==
** (CompileError) deadlocked waiting on struct B


Compilation failed because of a deadlock between files.
The following files depended on the following modules:

  lib/b.ex => A
  lib/a.ex => B

Ensure there are no compile-time dependencies between those files and that the modules they reference exist and are correctly named

if the matching is done inside of the function body, this can be used as an escape hatch to avoid struct field type checking:

defmacrop struct_of(module, fields \\ []) do
  fields = [__struct__: module | fields]
  quote do
    %{unquote_splicing(fields)}
  end
end

but this does not work for function header matching, of course it could be in a separate module and with a require statement it works.

Expected behavior

suggested improvements:

option 1: Add "avoids type checking macro" to the kernel.

option 2: memoize all struct patterns across compiled files and defer struct field checking till a later stage in the compiler pipeline.

option 3: improve the error message to declare the nature of the cyclic dependency and provide suggestions to fix

[josevalim]

Hi @ityonemo!

How do you suggest the cyclic dependency error message to be improved?

I think we could improve it so it actually has a stacktrace but it already says that B is waiting on A, A is waiting on B struct, and that you should look at compile-time dependencies.

option 2: memoize all struct patterns across compiled files and defer struct field checking till a later stage in the compiler pipeline.

We could introduce this but it would be valid only for patterns, as outside of patterns we do have to expand the whole struct. In this case, using %User{} in a pattern and in an expression would fail at distinct times in different ways, leading to a somewhat inconsistent experience... so I am not sure if we should add it.

[zachdaniel]

One small thing and one maybe bigger thing:

1. It may be clearer to rephrase or include %B{} in the error message somehow

== Compilation error in file lib/a.ex ==
** (CompileError) deadlocked waiting on struct B

Could be

== Compilation error in file lib/a.ex ==
** (CompileError) deadlocked waiting on struct B: %B{}

or just

== Compilation error in file lib/a.ex ==
** (CompileError) deadlocked waiting on %B{}

2. could we record the lines that incurred the dependencies? Especially useful for folks who don't know what does and doesn't incur a compile time dependency, if the message was:

== Compilation error in file lib/a.ex:4 ==
** (CompileError) deadlocked waiting on struct %B{}

or

== Compilation error in file lib/a.ex at line 4 ==
** (CompileError) deadlocked waiting on struct %B{}

it might be that little extra push?

[ityonemo]

If going the error route:

• when you're waiting on a struct maybe a gentle reminder that the compiler needs to be aware of what the struct looks like. If it's in a match, I would suggest a workaround too, "if you need to match on, %{struct: ...}"

• most importantly for both, a file:line would be great. In these simple cases it is obvious but in a much longer file you might be like "where do I have that??"

if going with memoization:

fail at distinct times in different ways

AFAICT this is transparent to the user, unless a module is taking a very long time in general I am not aware of what module the compiler is doing. I guess this could be different if I were listening to compiler hooks.

[josevalim]

AFAICT this is transparent to the user, unless a module is taking a very long time in general I am not aware of what module the compiler is doing. I guess this could be different if I were listening to compiler hooks.

The point is that it will no longer be transparent. One will fail during compilation and the other will emit a warning after compilation is over.