I want to know how to suppress errors in elixir. Ideally a few ways. Fixing them is not an option. We are slowly fixing them.
I’m currently working in a 7 year old umbrella project with many thousands of warnings, thousands of files. I’ve tried both our current elixir 1.15.6-otp-26 and elixir 1.16.0-otp-26. Which the newer version does have nicer looking errors, but is still not what i’m looking for. I’m wanting to optionally suppress the warnings when running tests or trying to identify compile errors locally. Ideally with a flag or shell var so that I can keep it enabled for ElixirLS.
The main motivation behind this is that the REAL errors get drowned in the sea of warnings. I literally have to use the search feature within my terminal to try and find the error. However, even this is terrible because a lot of the warnings include err or error which makes searching difficult.
I feel like in previous versions (i think ~1.14) of elixir the errors would short circuit compilation which at least left the error at the bottom of the output instead of hidden in the middle.
Given this context the best solution I can think of is leveraging compiler flags to minimize or suppress the warnings explicitly when running tests / iex locally. I’ve found a few things that seem like they may help, but I don’t know how to actually enable them / pass them to the erlang compiler.
Things i’ve sort of found, but have not figured out how to use correctly. A couple things i’ve looked at…
erlang compiler options, report_warnings , things like nowarn_unused_vars
if this is the right thing. how can I actually leverage it in elixir. I’ve looked at ERL_COMPILER_OPTIONS, but can’t seem to get it do do anything.
@compile :nowarn_unused_vars attribute in a module that generates warnings.
This seemed to have no impact…
Mix compile options, --no-all-warnings. I don’t think this is even what i’m looking for but I tried it. or any compile option that might help…
My coworker literally has a script to grep through the output to help filter down to the errors. I would hate for this to be our only solution…
External links that are related.
What’s blown my mind the most about this is that I feel nearly alone looking at a solution to this. I feel configuring the output of a compiler is a pretty important thing.
Anyhow, hope someone can help! Until then i’ll continue my trash workflow of swimming through warnings.
It wasn’t a short circuit, but afaik some changes in ordering of IO. But indeed that changed at some point.
There’s explicitly no way to do that afaik. It’s not a nobody is interested in this, but iirc an active choice made by the core team to not have a setting for that.
Out of curiosity, what are the warnings you are getting? I just ask as they could be easier to fix than you think, even on a huge project, using Sourceror.
I hope that’s not the case. I understand discouraging it, but why explicitly restrict it? What’s the benefit? Erlang seems to have the option to do it! I wonder if anyone has some forked elixir that I could just use locally. I wouldn’t know where to begin to patching it myself.
I appreciate the reply, but my goal is to avoid this sentiment and style of answer. I’m aware that everyone believes “fixing” the warnings is the correct way, and in a vacuum I agree. I’m also aware there are many ways to scan/update the source programatically. However, This is a higher risk operation that is less than ideal for our large prod codebase. Making huge sweeping changes across the entire codebase (even if trivial) is not something we want to do. In the log run we are working and chipping them away.
I do not need help understanding the fix for any particular warning type… they all make sense. They are not an explicit PROBLEM for us in our system. And some are even expected… There are many types, and it would take me some time to actually figure out comprehensively all of them but to list a few just for you…
module X is not available or is yet to be defined
variable "X" is unused. there is a variable with the same name in the context, use the pin operator (^) to match on it or prefix this variable with underscore if it is not meant to be used
X is deprecated. Use Y instead
def my_fake_func/1 has multiple clauses and also declares default values
unused alias Channel
module attribute @Y was set but never used
undefined module attribute @Y
missing parentheses for expression following "do:" keyword. Parentheses are required to solve ambiguity inside keywords.
This is just a sample what I see scanning with my eyes and not comprehensive. There are literally thousands of warnings.
All responses around this idea seem to end up with the same answer. Something along the lines of “just fix the warning” or “the warnings are telling you something is likely wrong with your code”. I hear that and disagree that it’s ALWAYS the case. So, at least here, please respond with direct answers within the scope of my question regardless of how you feel about it. This is why I explicitly said “Fixing them is not an option”.
Yep, that’s why I said could and was very careful not to use the word “just” (I know we all love when people start a sentence with “Can’t ya just…”). Yes, some of these would be very tough to fix programmatically so it’s not much help to you here. But there are certain classes of warnings that are easy and safe to programmatically fix which is why I asked.
I’m not sure why there is no option to disable warnings. My guess is that it is generally a dangerous thing to do. Warnings give us important feedback during development. If you blanket turned-off warnings then you’ll stop getting new ones as you dev. I could see this bringing up a whole new slew of complaints. I could see turning off everything except for deprecation warnings being useful but ya, I’m also pretty sure there is no way to do this. Again, this is a guess, I’m not on the core team nor do I contribute to the language.
I can’t post on that group. what’s the normal avenue to bring it to discussion with core team? I’de be interested in if they even think it’s hard. if it’s not hard i’ll happily fork elixir and use that locally…
The group is the place for elixir development discussions. I’ve posted there before without issues. Here might be seen by people as well. Github issue might be ok given the outlines issues you have as well, not sure about that one though.
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…
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.
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?
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.
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.
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!
. Appreciate it.
