Elixir > 1.2 throws compile-time warnings for unused variables

[Qqwy]

In Elixir >= 1.2.3, compile-time warnings are generated that tell that the variables in one of the defcall, defstart, etc. definitions are unused.

This is obviously not true, but it would be nice if the code could be restructured so the warnings would not be generated at all, as it becomes easy to miss other warnings that have to be acted upon.

[sasa1977]

I just tried with Elixir 1.2.5 and didn't get any warning. Could you provide a code which produces such warning?

Also, which version of ExActor are you using? There was indeed such bug in previous versions, but it's fixed in the latest one (2.2.0).

[Qqwy]

Thank you for your reply! :+1:

I am using version 2.2.0 of ExActor, and I am running version 1.2.5 of Elixir (and I am getting exactly the same warnings under version 1.2.3 and 1.2.4).

The project I am currently using ExActor for can be found on GitHub over here.

When (re-)compiling lib/alchemud/world/gen_location.ex, I get the following warnings:

lib/alchemud/world/gen_location.ex:13: warning: variable state is unused
lib/alchemud/world/gen_location.ex:13: warning: variable uuid is unused
lib/alchemud/world/gen_location.ex:32: warning: variable exit_name is unused
lib/alchemud/world/gen_location.ex:32: warning: variable exit_name is unused
lib/alchemud/world/gen_location.ex:32: warning: variable way is unused
lib/alchemud/world/gen_location.ex:32: warning: variable ways is unused
lib/alchemud/world/gen_location.ex:46: warning: variable entity is unused
lib/alchemud/world/gen_location.ex:84: warning: variable state is unused
lib/alchemud/world/gen_location.ex:10: warning: unused alias Entity
Compiled lib/alchemud/world/gen_location.ex

Similar warnings are made for lib/alchemud/world/gen_way.ex and lib/alchemud/world/gen_entity.ex.

Am I doing something wrong?

[sasa1977]

Thanks for the report. There was indeed a problem with compound matches, and it's now fixed and pushed to GitHub (but not yet to hex).

However, the fix will not solve all warnings. The remaining problems are the cases where a submatch of an argument is used only in the interface function:

defstart start_link(state = %Location{module: _, uuid: uuid}), 
    gen_server_opts: [name: {:global, {:location, uuid}}] 
do
  ...
end

The problem is that defstart generates two functions: start_link which uses uuid var, and init which doesn't use it. Thus, a warning is emitted.

I'm not sure I can do anything to reliably treat such situations. I could try to walk the AST of the body, to deduce which variables are in fact used in the callback function (init), and then mask the references in the match to init. But this would be quite convoluted, hard to reason about, and might possibly introduce some subtle bugs. So at the moment, I'm not inclined to attempt this.

A workaround for this could be to introduce a helper function:

defstart start_link(location),
    gen_server_opts: [name: process_name(location)]
do
...
end

defp process_name(%Location{module: _, uuid: uuid}), do: {:global, {:location, uuid}}

This is one example which demonstrates the weakness of ExActor. The problem is that macros such as defstart, defcall, and others generate two functions. That works fine when arguments are just plain vars. However, if you want to use more complex pattern matches, then there might be problems because it's hard (if not impossible) to guess whether the match should be applied in the interface function and/or in the callback function.

In any case, could you please give this a try (you need to change your dependency to point to GitHub), and let me know if it works.