elixir
elixir copied to clipboard
Compilation warning location "drift"
Elixir and Erlang/OTP versions
Erlang/OTP 26 [erts-14.2.2] [source] [64-bit] [smp:10:10] [ds:10:10:10] [async-threads:1] [jit]
Elixir 1.16.2 (compiled with Erlang/OTP 26)
Operating system
macOS 13.6.3 22G436
Current behavior
So I started noticing in this library that the "line of error" started to "drift" as I made changes to the code. Below you can see that for some reason it's pointing to a @doc for an unrelated function rather than the conflicting function. Anything you need for this I can provide.
12:52:52.547 [error] Exqlite.Connection (#PID<0.251.0>) failed to connect: ** (Exqlite.Error) database is locked
error: def create_sample!/3 defaults conflicts with create_sample!/2
│
30 │ preloaded relationships.
│ ^^^^^^^^^^^^^^^^^^^^^^^^
│
└─ lib/ecto_interface/write/create.ex:30: EctoInterfaceTest.SampleShorthandContext.create_sample!/3
== Compilation error in file test/ecto_interface_test.exs ==
** (CompileError) lib/ecto_interface/write/create.ex: cannot compile module EctoInterfaceTest.SampleShorthandContext (errors have been logged)
test/ecto_interface_test.exs:30: (module)
test/ecto_interface_test.exs:29: (module)
(elixir 1.16.2) lib/kernel/parallel_compiler.ex:540: Kernel.ParallelCompiler.require_file/2
(elixir 1.16.2) lib/kernel/parallel_compiler.ex:430: anonymous fn/5 in Kernel.ParallelCompiler.spawn_workers/8
Expected behavior
Point to the right macro line.
I've been getting moving warnings for a dependency, Slipstream, that keeps "drifting" to different parts of a doc.
Can you folks please provide a way to reproduce this bug? Something that I can run mix compile with some steps to see the drift. Thanks! :)
Yeah I'll get a zip of the entire directory when I get a chance, I have to induce the compiliation error again (i've since fixed it).
Ping. :) Please let me know if you folks have any updates. Thank you!
Ping!
I've tried my best to replicate the problem but I can't get the same result. Clearly I'm compiling in a test of my library ecto_interface, which works by chain use() (a uses b uses c, with location: :keep) and there's a @doc involved and the database is failing to lock. I suspect this "drift" is actually related to the dual issues of:
- The source module not being able to compile due to being interrupted
- The end-of-chain module being changed
- And an issue with the end-of-chain module
I tried the bare minimum of two projects with Slipstream using a path dep from one other to the other and could not reproduce. I will try stripping my monorepo down until I can get to the minimum that reproduces it.