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? On Thursday, January 11, 2024 at 2:31:18 PM UTC-5 Parker Hewitt wrote: > 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) > > On Tuesday, September 27, 2022 at 4:11:52 AM UTC-4 José Valim wrote: > >> 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. :) >> >> >> On Tue, Sep 27, 2022 at 9:25 AM Maciej Małecki <smt...@gmail.com> wrote: >> >>> 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). >>> >>> -- >>> 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 >>> >>> <https://groups.google.com/d/msgid/elixir-lang-core/0b7281bd-62ae-4a65-a153-eabfe90d5551n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/9019952b-7264-428f-ac4d-195706398dcdn%40googlegroups.com.
