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. On Fri, Jan 12, 2024 at 7:33 AM Derek Kraan <de...@kraan.dev> wrote: > 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. > > On Fri, Jan 12, 2024, at 00:42, Parker Hewitt wrote: > > 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 > <https://groups.google.com/d/msgid/elixir-lang-core/9019952b-7264-428f-ac4d-195706398dcdn%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/73f55317-dd18-4efc-b49b-4e606d995bab%40app.fastmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/73f55317-dd18-4efc-b49b-4e606d995bab%40app.fastmail.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/CAGnRm4%2BFTjFNRzLY2p8DeqTkrr_uNZUk3KRH%2BdDSkw6pKUMu_w%40mail.gmail.com.
