Incremental compilation bug (or undefined behaviour?)

Questions / Help
, ,
1

Inter-module dependency tracing bug

Consider this module

defmodule XXX do
  module = String.to_atom("Elixir." <> "YYY")
  @x apply(Enum.at([module, ZZZ], 0), :func_y, [0])
  def x do
    @x
  end
end

It is clear that it depends on YYY module in compile time, but

  1. when YYY is changed and recompile (or just mix) is called, XXX is not recompiled.
  2. when ZZZ is changed and project recompiled, XXX is recompiled, but it is clear that ZZZ is not called in compile time

Is this a correct behavior or not?

2

Our compile time tracking is based on lexical information and not runtime tracing. So if you hide the module by dynamically generating it, then incremental compilation won’t be applied.

3
  1. It is not dynamically generated, it is generated in compile time
  2. Things like alias and require as are still tracked though
  3. Things from macro expansion are tracked too
  4. In this example,
YYY
defmodule XXX do
  ...
end

Recompiling when YYY changed causes XXX to be recompiled too.

So, I am guessing that after every macro expansion and unaliasing, compiler just takes all atoms starting with Elixir. from external context and module body (but not from def*) and marks current module dependent from them, right?

4
  1. The atom is dynamically generated at compile time.

—-

Elixir tracks it during expansion, not after.