I had to join the group first 
. Appreciate it.
phewitt
Cochonours
did you try piping your command through a script that would remove every line that looks like a warning and print the others? It’s not ideal but given there seem to be no easy way…
1
phewitt
Yeah that’s essentially what a couple coworkers do… It’s error prone and the output of compiler seems to change every version.
But yeah that’s the only real solution i’ve seen get even close to what i’m wanting… Seems so strange to me to remove a feature that exists in erlang itself.. as well as other languages typescript, c++, etc … I feel like having a “I know what i’m doing” back door is important. Sometimes you intentionally do things that draw warnings.
Overall at a minimum I think all Elixir compiler ERRORS should show at the bottom of the output. At least then I could ignore 99% of the output.
2
peixian
I made a fork of elixir that suppresses warnings, if you compile the fork, it outputs errors as expected in v1.16, and is silent otherwise: GitHub - peixian/elixir-no-warn at peixian/v1.16-no-warnings · GitHub
Specifically this gets the diagnostics to only return the errors: Only emit errors · peixian/elixir-no-warn@8538945 · GitHub
2
Onor.io
You know I actually wished more languages took the approach of not allowing warnings to be suppressed (or at least developers were forced to deal with them). Think about what a warning is (at least in languages like C and C++). A warning is something the compiler author feels needs to be brought to your attention. Maybe you’re intentionally casting a 64-bit integer to a 32-bit unsigned integer (to offer one ridiculous example) which is legal but maybe not what you meant to do.
I love the fact that the same people who insist on 100% test coverage never bother to turn the warning level to 4 and never bother to have their warnings treated as errors. To me this is a simple, cheap way to catch potential bugs at compile time. Sorry–I’m digressing.
You’re facing the result of 7 years of people not dealing with warnings. Yes, it’s a pain in the ass to deal with all those warnings when something you want to know about may be hidden but ignoring them is not really a great answer either.
I once saw a bug in some C++ code that came down to this:
if (x = 1)
{
Of course what they meant to type was if(x == 1) and the compiler warned them about assignment in the conditional test but they had ignored compiler warnings (for years as far as I could tell). Something like this jumps right out when I type it on a line by itself but buried in thousands of lines of code, it’s a bit harder to catch. At any rate, I set the C++ compiler to treat warnings as errors and this popped right out.
Ignoring warnings is a path to large chunks of technical debt (to say the least). Bite the bullet and get rid of the warnings that have built up over 7 years. I suspect the reason you don’t want to deal with the warnings is that you haven’t got time–tight deadline or something of that sort. But if you suppress or continue to ignore warnings you’re just kicking the can down the road. I mean how do you know that those warnings you’re trying to suppress aren’t pointing out real issues in your code?
Just my $.02.
6
peixian
I suppress warnings because I hate the recent IO diagnostic change that forces me to search for errors within a sea of warnings, instead of putting the error as the last line when the compilation terminates.
6
Onor.io
Again, perhaps my experience is different than yours but I think ignoring warnings is a dangerous habit to get in to.
1
phewitt
I knew this type of response would show up here like all the other places… Again, in a vacuum I agree with you. Warnings can be helpful. If I started a fresh project I would probably use the warning-as-error or whatever flag to help keep them from happening at all (however idk what you would do if you actually had an intentional warning).
We have been actively addressing them as we go. Typically if we touch a file that has some we address them. I don’t want them always suppressed, I want to optionally disable them. I love my IDE underlining it in yellow, I want CI showing it, I want to see it when I build sometimes too. I want the flexibility to leverage it when it’s useful and turn it off when it’s literally not useful.
I want to be pragmatic with my solution I have and not dogmatic about all warnings are or are not the enemy. I believe there is nuance in most things, this included.
It totally could be signs of “real” issues. But clearly not any major issues because they’ve been there for years and our system has served millions of users just fine with all of them there! Like worrying about an unused variable is hardly a cause for concern generally… and yes some very niche edge case it could help identify, but we are past the point of no return. To me there is a difference between like theoretically a problem and actually a problem, and most of our warnings are theoretically a problem.
6
sodapopcan
To be fair, I think @Onor.io is responding to is:
and
I think the vast majority of Elixirist don’t have the need to silence warnings, so it doesn’t come up very much.
I also don’t think that precedent set by well-known languages—or even the language Elixir is built-off—is an argument for allowing it. Newer languages fix old, bad ideas. Of course, people in your situation end up being collateral damage which I agree is unfortunate—Inheriting a codebase where those before you were careless is all-around not a good time.
But ya, I’m speculating again. Will be interesting to see the response on the mailing list! 
4
phewitt
Yah that’s fair about other languages. And you’re probably right that’s what he’s responding to.
How about this at a minimum. Could we all agree that a compile error is of more urgency when compiling than a warning? To Pexians point, the main frustration is the warnings drowning our errors more than the warnings themselves.
1