-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mix.Project.config/0 sometimes doesn't return the project configuration #717
Comments
@sasa1977 do you have this error in a phoenix project with reloader? It uses a similar approach to recompilation. |
Just tried the following:
Result:
|
Adding a data point - I have this issue as well elixir 1.12.3-otp-24 |
While we wait for a fix, here is a workaround (no sure if this is the best env var to check for, but it seems to work) # Workaround to avoid Boundary breaking ElixirLS:
# ElixirLS runs with the ELS_MODE env var set, so we disable the
# Boundary compiler in that case.
# See https://github.com/elixir-lsp/elixir-ls/issues/717
@use_boundary (if System.get_env("ELS_MODE") do
[]
else
[:boundary]
end)
def project do
[
# ...
compilers: @use_boundary ++ [:other :compilers] ++ Mix.compilers(),
# ...
]
end |
@sasa1977 after some debugging this looks like a problem in
Here's what happens when the build fails
And then after fixing build
|
Hmm it may be difficult to properly implement cleanup as it seems that when build fails Edit: |
Thanks for debugging! Looking at the boundary code, it doesn't seem correct. The tracer is cleared on success, but not on error. I'll try the fix tomorrow and report back, although your follow-up report suggests that an Elixir bug also has to be fixed. Either way, I'm a bit confused, because this used to work just fine up until recently. I suppose something has changed in the way ElixirLS recompiles the project, right? |
Yeah, I've fixed the behaviour in boundary, but the error still appears, because the callback is not invoked, so I guess we'll have to wait for the Elixir fix. |
I'll try the workaround with clearing tracers |
FYI, I took the approach advised in elixir-lang/elixir#12159 (comment) (cleaning up the tracers after the Elixir compiler) and this resolved the issue. The fix is published on hex in boundary 0.9.4. Thanks for helping troubleshoot this. |
Environment
Current behavior
I'm investigating crashes in the boundary library. These crashes take place only when the project is built inside ElixirLS.
For the purpose of this report, it's enough to know that boundary is a custom compiler which invokes Mix.Project.config/0 to get the project configuration.
It appears that in some situations,
Mix.Project.config/0
isn't returning the project config, but rather some generic default template. As the docs state: If there is no project defined, it still returns a keyword list with default values. This allows many Mix tasks to work without the need for an underlying project.. This is only happening in ElixirLS, and only after the previous compilation failed due to an error.Here are steps to reproduce:
mix new my_app
In mix.exs add
{:boundary, "~> 0.9"}
as a dep, and fetch deps.In my_app.ex add
use Boundary
to theMyApp
module.In mix.exs add
compilers: [:boundary | Mix.compilers()]
inproject/0
. Only do this after step 3, or otherwise ElixirLS will crash due to another bug (which I need to fix in the boundary lib).Make sure that the project is compiling from ElixirLS (I used vscode for testing, and observed the output view).
Introduce a compilation error in my_app.ex, e.g.:
Wait until the compilation fails, then fix the error. At this point, the boundary compiler will crash with:
Notice the keyword list which is inspected in this output. This list is obtained via
Mix.Project.config()
, but it doesn't correspond to the actual project config. For example the:app
key is missing, as well as the:compilers
key.Restarting ElixirLS will fix the issue. I wasn't able to reproduce the problem outside of ElixirLS. Due to this, it seems that the problem is somehow related to the way ElixirLS builds the project after a failed compilation.
Expected behavior
Mix.Project.config/0
should always return the correct project configuration.The text was updated successfully, but these errors were encountered: