Raise warnings during compile time

I’ve forked an abondoned hex-package and continue to maintain it under a new name.

The old code-base does provide a macro that we call finalize/0 for the purpose of this thread. This macro does its work depending on some module-attributes which are filled by other macros (which I do not need to explain here, just consider them similar to the test macro of ex_unit).

Now I want to move the functionallity of this finalize/0-macro into __before_compile__/1-macro and add a proper deprecation warning to finalize/0.

Such that a warning is emitted during compiletime when someone still uses finalize/0 and the hint that it is handled automatically in the current version and that the feature will get completely removed with version X. But how? I did not find anything in the documentation.

2 Likes

Currently I just use Logger.warn/2 to get some output at least, but this doesn’t feel right. I’d prefer a way that makes the compiler aware of the warning, such that someone who compiles with warnings as errors will have a failing build.

You can do this:

warn.ex:

defmodule Foo do
  defmacro __using__(_opts) do
    :elixir_errors.warn __ENV__.line, __ENV__.file, "this is compilation warning"
  end
end

defmodule Bar do
  use Foo
end

and when compiling you get:

$ elixirc --warnings-as-errors warn.ex 
warn.ex:3: warning: this is compilation warning
Compilation failed due to warnings while using the --warnings-as-errors option
$ rm *.beam                           
$ elixirc warn.ex                     
warn.ex:3: warning: this is compilation warning

In both cases warning is printed to the stderr while compilation. In first case, however, compilation fails and appropriate shell exit code is set. In second case only warning is printed.

@Edit: https://github.com/search?utf8=✓&q=elixir_errors+language%3Aelixir&type=Code&ref=searchresults

Looks like it’s ok to do that, but better in this form:

%{file: file, line: line} = __CALLER__
:elixir_errors.warn(line, file, "error")
6 Likes

On a more general note, you could write a function decorator for this, like this:

  defmodule DeprecationDecorator do
    use Decorator.Define, deprecated: 0

    def deprecated(body, context) do
      :elixir_errors.warn __ENV__.line, __ENV__.file, "Function #{context.module}.#{context.name}/#{context.arity} is deprecated"
      body
    end
  end

Which you would use like this:

defmodule SomeModule do
  use DeprecationDecorator

  @decorate deprecated
  def old_function_do_not_use() do
    # ...
  end
end

[/end shameless library-plug] :slight_smile:

1 Like

TL;DR - Don’t do this. Use IO.warn(msg, Macro.Env.stacktrace(env)).

Please don’t do this.

:elixir_errors is a private module. It is undocumented. It is internal to Elixir only. It is not meant to be accessed by other libraries besides Elixir. There is no guarantee it will continue working on future releases.

Relying on private functions it is very harmful. In the future, if such practices are wide-spread, one of the two things will happen:

  1. We won’t be able to improve Elixir, or improving it will be more complex, because developers are relying on APIs they should not, and we will need to phase them out first

  2. Packages will break on new Elixir versions, which will make it harder for people to migrate to future Elixir versions, or give the impression the ecosystem is fragile (which would be if new Elixir versions are breaking supposedly valid code).

Please don’t rely on private APIs. Not for Elixir, not for other libraries. It is more harmful than you may think.

12 Likes

This is great. I am terribly sorry to post misleading message, it was the thing I saw somewhere and adopted.

➜  elixir  cat warn.ex                         
defmodule Foo do
  defmacro __using__(_opts) do
    msg = "this is compilation error"
    IO.warn(msg, Macro.Env.stacktrace(__ENV__))
  end
end

defmodule Bar do
  use Foo
end
➜  elixir  elixirc --warnings-as-errors warn.ex
warning: this is compilation error
  warn.ex:4: Foo.__using__/1

Compilation failed due to warnings while using the --warnings-as-errors option

This is way better, however!

Edit: ah yeah it’s plenty of wrong usage in different libs then:

low hanging fruits if someone wants to make some pull requests.

2 Likes

No problem! Although Discourse shows I replied to you, it was really to everyone that is using private APIs, here or on GitHub. :wink:

4 Likes