Exadra37
Why is not compilation aborted when an undefined module attribute is found?
A bug going into production without any need:
warning: undefined module attribute @seconds, please remove access to @seconds or explicitly set it before access
lib/api_baas/accounts_admins/admin_user_token.ex:120: ApiBaas.AccountsAdmins.AdminUserToken (module)
Yes, tests should caught it, but why doesn’t the compiler abort compilation when it finds this?
Yes, I know that warnings can be enabled to behave as errors, but some warnings need to behave as warnings, and not halt the compiler.
I am curious about the reason for this to be considered as an warning and not an error?
Most Liked
al2o3cr
I only have 1.13 + OTP 25 right at hand to test, but on that version I still get the same warning from plug when running mix compile --warnings-as-errors with an empty _build directory.
However, --warnings-as-errors doesn’t turn warnings in dependencies into errors.
Some historical digging reveals that it used to; around the time of Elixir 1.4 that was changed, by commits like:
hst337
Just use --warnings-as-errors which is a sane option for CI
Exadra37
For example:
==> plug
Compiling 1 file (.erl)
Compiling 41 files (.ex)
warning: System.stacktrace/0 is deprecated. Use __STACKTRACE__ instead
lib/plug/conn/wrapper_error.ex:26: Plug.Conn.WrapperError.reraise/3
==> ecto_sqlite3
Compiling 4 files (.ex)
warning: function query_many/4 required by behaviour Ecto.Adapters.SQL.Connection is not implemented (in module Ecto.Adapters.SQLite3.Connection)
lib/ecto/adapters/sqlite3/connection.ex:1: Ecto.Adapters.SQLite3.Connection (module)
hst337
Elixir’s code states that it is a known issue and they just don’t want to add breaking change
# TODO: Consider raising instead of warning on v2.0 as it usually cascades
al2o3cr
I’m curious about what these are, because I can’t remember the last project I worked on that didn’t build with --warnings-as-errors in CI.








