I’m updating a project from Elixir 1.13 to Elixir 1.14. I have dependencies on both slime and conform. Both these projects use the peg compiler, and this is creating a problem. If it caused it on 1.13 I didn’t notice. The problem is that both mix files invoke the peg compiler on tasks/compile.peg.exs. Both files define Mix.Tasks.Compile.Peg. With the 1.14 compiler when I do a deps.compile it will compile slime first and conform second, and conform errors because it appears to be reusing the Compile.Peg file compiled for slime. I don’t see a way around this in a deps.compile. It seems to resolve itself if I just do a mix compile.

I played around in conform for a while. I tried changing the file name, the module name, and some other things, and it seems like the peg compiler is fairly fixated on using those names.

The error is:

could not compile dependency :conform, "mix compile" failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile conform", update it with "mix deps.update conform" or clean it with "mix deps.clean conform"
** (File.Error) could not read file "src/slime_parser.peg.eex": no such file or directory
    (elixir 1.14.5) lib/file.ex:358: File.read!/1
    (eex 1.14.5) lib/eex.ex:259: EEx.compile_file/2
    (eex 1.14.5) lib/eex.ex:300: EEx.eval_file/3
    /var/lib/ucxbuild/infinity_one/deps/slime/tasks/compile.peg.exs:15: Mix.Tasks.Compile.Peg.run/1
    (mix 1.14.5) lib/mix/task.ex:421: anonymous fn/3 in Mix.Task.run_task/4
    (mix 1.14.5) lib/mix/tasks/compile.all.ex:92: Mix.Tasks.Compile.All.run_compiler/2
    (mix 1.14.5) lib/mix/tasks/compile.all.ex:72: Mix.Tasks.Compile.All.compile/4
    (mix 1.14.5) lib/mix/tasks/compile.all.ex:59: Mix.Tasks.Compile.All.with_logger_app/2

Note that although this is the conform compile it is trying to execute deps/slime/tasks/compile.peg.exs:15: Mix.Tasks.Compile.run/1.

Looking down the stack trace (1.14.5-otp-25) it looks like this problem might come from Mix.Task.run_task, which despite compiling conform, finds the Compile.Peg module in the slime directory.

Is this something I can fix in the mix files for either slime or conform by cleaning the Peg module after/before compiling so that the two don’t mix, or should this be the responsibility of the compiler to find the right module?

This duplicates with a really simple new project, using the following mix.exs:

defmodule CompilePeg.MixProject do
  use Mix.Project

  def project do
    [
      app: :compile_peg,
      version: "0.1.0",
      elixir: "~> 1.14",
      start_permanent: Mix.env() == :prod,
      deps: deps()
    ]
  end

  # Run "mix help compile.app" to learn about applications.
  def application do
    [
      extra_applications: [:logger]
    ]
  end

  # Run "mix help deps" to learn about dependencies.
  defp deps do
    [
      {:slime, "~> 1.0"},
      {:conform, github: "infinityoneframework/conform"}
      # {:dep_from_git, git: "https://github.com/elixir-lang/my_dep.git", tag: "0.1.0"}
    ]
  end
end

With 1.13.3-otp-24 I get a single warning, which actually makes me think that the order of the output might be a little off, but the output looks like this:

mix deps.compile
WARN:  Missing plugins: [rebar3_hex]
==> neotoma (compile)
Compiled src/neotoma.erl
Compiled src/neotoma_parse.erl
Compiling src/conform_parse.peg
PEG manifest updated
==> conform
Compiling 1 file (.erl)
Compiling 20 files (.ex)
Generated conform app
warning: redefining module Mix.Tasks.Compile.Peg (current version defined in memory)
  /var/src/compile_peg/deps/slime/tasks/compile.peg.exs:1

'/var/src/compile_peg/deps/slime/src/slime_parser_transform.erl' already exists, skipping generation.
==> slime
Compiling 2 files (.erl)
Compiling 11 files (.ex)
Generated slime app

(The part that seems odd is that the warning about recompiling the Peg module is printed about the path in slime, even though the compiler hasn’t yet printed the slime name. Is the name printed after some of the work is already done (or queued while the errors are output directly)?)

Is this a compiler problem (likely yes since it didn’t happen with the 1.13 compiler), and/or is there a workaround that I might be able to add in one of the projects?