Browse files

Merge pull request #42 from ericmj/compat-17

Compatibility with 17.0-rc2
  • Loading branch information...
2 parents 3cc20d0 + 5ceae40 commit 64e1eaef0b1e88849c7e7ba9ff75f8cd4dba2a3b @devinus committed Feb 28, 2014
Showing with 1 addition and 1 deletion.
  1. +1 −1 rebar.config
@@ -1,3 +1,3 @@
-{erl_opts, [debug_info, warnings_as_errors]}.
+{erl_opts, [debug_info]}.
{eunit_opts, [verbose]}.
{cover_enabled, true}.

8 comments on commit 64e1eae

Looks like this also can be fixed by just -compile(nowarn_deprecated_type).


ericmj replied Apr 10, 2014

@seriyps At the time this change was made nowarn_deprecated_type didn't exist. If poolboy is not going to support the 17.0 release candidates it can be changed to -compile(nowarn_deprecated_type).

Why don't you want just fix two queue type entries instead?


ericmj replied Apr 11, 2014

@maximvl Because that breaks R16.

@ericmj What about -type queue() :: queue:queue(). ? I'm too lazy to try this on R16 now :)


ericmj replied Apr 11, 2014

@maximvl That may work, please go ahead and try it. Regardless, disabling warnings_as_errors is a good idea anyway, just because of issues like this. Making warnings produce errors should only be used in development, with rebar this setting will be used when poolboy is used as a dependency. Which is bad.

When many developers use warnings as errors it limits language development because adding warnings will be a breaking change, as was the case here. There is a reason warnings are warnings - don't make them errors.

[/rant] :)


ddosia replied Apr 18, 2014

@ericmj I am sorry to intrude, and start this discussion, but this really interesting for me: how do you think this may happen? Say today we have R16, and next day boom, somehow ubuntu pulls new shiny 17.0? and b/c of warnings_as_errors everything is broken? I mean if you going to change erlang major version you possible want to do some work on the libraries, maybe to update some of them. In worst case just go straight to bad library and comment this line.
Right now if warnings_as_errors is disabled by default nobody bothers to turn it on and just left bad code as is.
I see warnings_as_errors as a way to force someone to do nitty-gritty work.


ericmj replied Apr 18, 2014

@ddosia No problem, I am happy to elaborate.

The Erlang OTP team wants to change the usage of queue() to queue:queue(). This is of course a breaking change. We don't like sudden breaking changes and the OTP team definitely doesn't like them. That is why they are first introducing it as a warning and intend and will let it be only a warning for an entire major version.

Warnings are, among other things, used as a tool for language developers to phase in breaking changes. Now, what the OTP team intended doesn't work here because warnings_as_errors is enabled. That means we are actively working against the intentions of the language developers.

At the time when this commit was made (17.0-rc1) there was no way to work around this warning while still maintaining compatibility with R16 and without using ugly preprocessor hacks. Fortunately this was fixed in time for the release of 17.0 stable with the addition of the compiler flag nowarn_deprecated_type.

warnings_as_errors is good at forcing developers to fix warnings. But the option should ONLY be enabled for developers of the library, never for users of the library.

nowarn_deprecated_type has the effect of completely hiding the warning. Is that really better if you want to force people to fix the library? I would rather disable warnings_as_errors and see the warning to remind me to fix it rather than removing it from the output entirely.

Please sign in to comment.