Proposal: Support for opting out from specific warnings

[Maciej Małecki]

Erlang supports disabling a given warning using compilation configuration (see https://www.erlang.org/doc/man/compile.html). There are use cases for letting developers decide what they treat as a warning and what not. For instance, I'm using `--warnings-as-errors` when compiling the code for production. However, it is impossible to use `deprecated` tags anymore as the complication will fail. I treat deprecations special here because some refactorings can't be done in a single run or some of them don't make sense as the code is legacy anyway.

I know that there is a `doc deprecated: "..."` mechanism, but it just feels right to use `deprecated` and still allow the `--warnings-as-errors`. The difference between those two would be: no warning during the compilation, but still logging the message when invoking the function.

This could be implemented similarly to `no_warn_undefined` (see https://hexdocs.pm/elixir/1.14.0/Code.html#put_compiler_option/2).

[José Valim]

At the moment we have don't have plans to introduce options to skip warnings, except if the warnings may have false positives.

For deprecation, typically doing it in two steps is the recommended option, especially for libraries: a couple releases with "@doc deprecated" and then the official deprecation. :)

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/0b7281bd-62ae-4a65-a153-eabfe90d5551n%40googlegroups.com.

[Parker Hewitt]

I too would find a lot of value in this or. Here is the thread that brought me here, https://elixirforum.com/t/how-can-i-suppress-warnings-ive-been-looking-for-a-while/60912

It seems y'all are pretty adamant about not supporting this, but what do you think would be the level of effort to have some rough take on it? If it's a rather small change I would consider building my own fork just to use personally.

my three ideas.
1) per warning type suppression
2) warning suppression entirely
3) separate warning and error output via (stdout for warning, and stderr for error)

[Parker Hewitt]

Also, i'd like to mention, really the true reason I am looking for a way to suppress the errors is because i'm having hard time finding compile errors in a large swath of compiler warnings.

I believe at some point the compiled errors used to show up at the end of the compiler output, but something changed that changed the behavior 1.15 maybe? Now it feels like the errors are printed when they are found by the compiler rather at the end of compilation. Was this an intentional change or a regression of some sort?

I personally feel that while maybe suppressing warnings is contentious, showing compiling errors is a higher priority when compiling than warnings. Errors keep my program from running at all. Warnings might point out a potential problem within my program runtime.

Is this on anyones radar?

[Derek Kraan]

I have also noticed this. Oftentimes, the error that broke compilation is not at the bottom anymore. I have also experienced this as a regression in terms of usability, but somehow it hadn't occurred to me to tell anyone about it.

I didn't see anything in open issues, nor in the changelog for 1.16. I am not a maintainer, but opening an issue on github seems reasonable to me.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/9019952b-7264-428f-ac4d-195706398dcdn%40googlegroups.com.

[José Valim]

Elixir v1.16 only prints all other warnings if there are no failures, to help with these use cases. If you still find it hard to find the actual failures in v1.16, please open up an issue.

Other than that, there are still no plans for "per warning type suppression", unless the warning has false positives.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/73f55317-dd18-4efc-b49b-4e606d995bab%40app.fastmail.com.