Some aliases are considered unused by the compiler

[joshprice]

Consider this resource definition:

  alias X.Entity
  alias X.Repo
  alias X.Api

  postgres do
    repo Repo
    table "..."
  end

  code_interface do
    define_for Api
    ...
  end

  attributes do
    relationships do
      belongs_to :entity, Entity
    end
  end

• Code compiles fine ✅
• Aliasing X.Api produces no warning ✅
• Aliasing X.Repo and X.Entity produces unused alias warning ❌

Expected behavior

No unused alias warnings should be produced

Runtime

• Elixir version 1.13.3-otp-24
• Erlang version OTP 24.3.3
• OS macos
• Ash version main
• Ash postgres main

Additional context

Replicated on 2 diff machines, diff editors

[zachdaniel]

Yeah, this one is very strange... I haven't been able to figure out why this is the case but only sometimes.

[sevenseacat]

an unused alias warning is also raised if the modules are used in action blocks, eg.

alias MyApp.SetInitialPosition

actions do
  create :create do
    change SetInitialPosition
  end
end

This appears to be a relatively recent change - I wasn't seeing this on Ash 1.51.2 but am on main.

[zachdaniel]

Okay, so the problem here is that in some cases, so as not to induce an unnecessary compile-time dependency, we do some magic 🪄.

https://github.com/ash-project/ash/blob/main/lib/ash/dsl/extension.ex#L1296

In one of my personal projects, if I remove the lexical_tracker: nil aspect of that, it resolves the unused alias warnings (I don't use aliasing anywhere in my resources personally). However, it also takes one of my resources from 1 file compiling on change to 18 files compiling on change. So the ideal thing here is to find some way to make the alias usage warning go away while keeping the compile-time optimizations. Which I'm not entirely sure is possible.

[zachdaniel]

https://github.com/bartekupartek/ecto/commit/48eb6fcbe4e04170912fdaf10cc3fd8dd8b4391d

This is what ecto has done to solve for this. Perhaps we should do the same and find a solution to what appears to be unnecessary compile time dependencies elsewhere.

[zachdaniel]

Alright, I'm going to remove the lexical_tracker: nil from all of these. This will stop us from being too...offensive to the elixir compiler. We will see if people report problematic compile times as a result.

[zachdaniel]

This should now be resolved in main

[joshprice]

Was resolved in https://github.com/ash-project/ash/commit/74cc7c4ad5158dd1989cdca88f0d08b5e8df6dbc but has reportedly reintroduced longer compile times.

This could also be resolved by explicitly turning alias warning flags off with alias X.Y.Z, warn: false. See https://hexdocs.pm/elixir/1.12/Kernel.SpecialForms.html#alias/2-warnings

[kernel-io]

I'm experiencing longer compile times as a result of this change, I went from having my custom change modules having 0 compile time deps, to having in excess of 50 deps. I think warn: false for some aliases will be our best bet to keep a reasonable DX.

[zachdaniel]

Yeah, I've had to put this back in place in main because the effect on compile times is unreasonable. What I will try and do is find a way to detect that the value has been aliased, and provide/helpful message if possible.

[zachdaniel]

Alright, so some more information can be found here: I've introduced something that should help in many cases, but will produce these warnings again unfortunately. However, in elixir 1.14 there will be tools for me to avoid those warnings. Until then, warn: false will need to be used.

https://groups.google.com/g/elixir-lang-core/c/3TG_Oc6uWDU

[joshprice]

Assuming you changed things in this commit? https://github.com/ash-project/ash/commit/c71587642de5f6fb149598398a149b228bec90f5

[zachdaniel]

It was this one, that one was purely cosmetic (for the code in question). https://github.com/ash-project/ash/commit/d29cc547258fda4428268bad6a60fb55c07644b1 I basically just put back the old behavior but only for certain specific dsl options.

[zachdaniel]

We should be able to emulate what was done here: https://github.com/elixir-lang/elixir/commit/828c6026a819bb168c7e4088323ffc8142c6daac

If we do that, we won't have to wait on a new release of Elixir.

[joshprice]

Elixir 1.14 is here, where does that leave this issue?

[zachdaniel]

Unfortunately, there isn't actually a fix for this in 1.14. I've raised the issue again with a potentially better explanation here: https://groups.google.com/g/elixir-lang-core/c/eOqotA8OyKE

[zachdaniel]

Fixed in latest release of spark!