New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why is Dialyzer's -Wunknown
off by default?
#5695
Comments
Could it be done in order to support hot code upgrades (where a module/function may appear)? |
@max-au, I believe so. I don't have an "official view" but that's what makes sense to me, too. |
I don't know reasoning behind the decision, but I think it's partly because you might want to run Dialyzer on part of a codebase for speed and also it fits with Dialyzer's philosophy to only warn for things that Dialyzer is sure is wrong. We will not change the default in OTP 25. We will postpone to OTP 26 the decision on whether the current default makes sense or whether it should be changed. |
I think it would be a good idea to make |
I perhaps should have been clearer in the original post: I really did intend this as a question of history and original intent to aid my own understanding, rather than a proposal to change things. That said, I am happy if the question sparks a debate and results in some sort of improvement for users of OTP. The point made above about hot code reloading is an interesting one, and makes sense to me. My question very much came from my personal experience, where I have all my code and dependencies available at build and analysis time, and I run Dialyzer over everything on every change to stay on top of the warnings. I appreciate this isn't necessarily reflective of how some (or even most?) people use Erlang and OTP, so it makes sense that the option default to something that supports the majority of users. |
Agreed. It would take a poll to get those results, though. I've run into the same issue, but always keep the same |
I'm wondering if it really is or isn't the case. I'm aware that loadable Linux modules are often built out of the source tree using just header files due to the sheer size of the kernel tree, but are modules of Erlang systems really built without access to an entire project codebase? The argument that static type checking cannot work for Erlang because of hot code reloading resonates in the community, but I'm not really convinced by it. Even in the light of type discrepancies between versions of code (let's say a currently running version and a version to be loaded), we would still like the version in development (so the one to be loaded at some point in the future) to type check - I see no reason whatsoever why we wouldn't. Then, if a hot-loaded module is not type-consistent with a version it's loaded into... we still have the supervision tree and in the worst case can "let it crash" during the transition from the old version to the new one. |
Hypothetically, if |
Dialyzer warnings about unknown functions and types are enabled by default. Prior to this commit, Dialyzer used to have disabled (by default) warnings about unknown types and functions. This default value has been overwritten; Dialyzer now warns about unknown types and functions (as requested by the community in erlangGH-5695). Thus, the following two examples are equivalent, i.e., passing the `-Wunknown` function is enabled by default: ``` dialyzer moduler.erl -Wunknown -Wmissing_return dialyzer moduler.erl -Wmissing_return ``` Dialyzer has a new flag, `-Wno_unknown`. Its purpose is to supress warnings about unknown functions and types. Users who wish to suppress these warnings can invoke Dialyzer using this flag. Example: ``` dialyzer module.erl -Wno_unknown ```
Dialyzer's warnings about unknown functions and types are enabled by default. Prior to this PR, Dialyzer used to have disabled (by default) warnings about unknown types and functions. This default value has been overwritten; Dialyzer now warns about unknown types and functions (as requested by the community in erlangGH-5695). Thus, the following two examples are equivalent, i.e., passing the `-Wunknown` function is enabled by default: ```bash dialyzer moduler.erl -Wunknown -Wmissing_return dialyzer moduler.erl -Wmissing_return ``` Dialyzer has a new flag, `-Wno_unknown`. Its purpose is to supress warnings about unknown functions and types (erlangGH-5995). Users who wish to suppress these warnings can invoke Dialyzer using this flag. Example: ```bash dialyzer module.erl -Wno_unknown ```
Dialyzer's warnings about unknown functions and types are enabled by default. Prior to this PR, Dialyzer used to have disabled (by default) warnings about unknown types and functions. This default value has been overwritten; Dialyzer now warns about unknown types and functions (as requested by the community in erlangGH-5695). Thus, the following two examples are equivalent, i.e., passing the `-Wunknown` function is enabled by default: ```bash dialyzer moduler.erl -Wunknown -Wmissing_return dialyzer moduler.erl -Wmissing_return ``` Dialyzer has a new flag, `-Wno_unknown`. Its purpose is to supress warnings about unknown functions and types (erlangGH-5995). Users who wish to suppress these warnings can invoke Dialyzer using this flag. Example: ```bash dialyzer module.erl -Wno_unknown ```
Dialyzer's warnings about unknown functions and types are enabled by default. Prior to this PR, Dialyzer used to have disabled (by default) warnings about unknown types and functions. This default value has been overwritten; Dialyzer now warns about unknown types and functions (as requested by the community in erlangGH-5695). Thus, the following two examples are equivalent, i.e., passing the `-Wunknown` function is enabled by default: ```bash dialyzer moduler.erl -Wunknown -Wmissing_return dialyzer moduler.erl -Wmissing_return ``` Dialyzer has a new flag, `-Wno_unknown`. Its purpose is to supress warnings about unknown functions and types (erlangGH-5995). Users who wish to suppress these warnings can invoke Dialyzer using this flag. Example: ```bash dialyzer module.erl -Wno_unknown ```
Dialyzer's warnings about unknown functions and types are enabled by default. Prior to this PR, Dialyzer used to have disabled (by default) warnings about unknown types and functions. This default value has been overwritten; Dialyzer now warns about unknown types and functions (as requested by the community in erlangGH-5695). Thus, the following two examples are equivalent, i.e., passing the `-Wunknown` function is enabled by default: ```bash dialyzer moduler.erl -Wunknown -Wmissing_return dialyzer moduler.erl -Wmissing_return ``` Dialyzer has a new flag, `-Wno_unknown`. Its purpose is to supress warnings about unknown functions and types. Users who wish to suppress these warnings can invoke Dialyzer using this flag. Example: ```bash dialyzer module.erl -Wno_unknown ```
Dialyzer's warnings about unknown functions and types are enabled by default. Prior to this PR, Dialyzer used to have disabled (by default) warnings about unknown types and functions. This default value has been overwritten; Dialyzer now warns about unknown types and functions (as requested by the community in erlangGH-5695). Thus, the following two examples are equivalent, i.e., passing the `-Wunknown` function is enabled by default: ```bash dialyzer moduler.erl -Wunknown -Wmissing_return dialyzer moduler.erl -Wmissing_return ``` Dialyzer has a new flag, `-Wno_unknown`. Its purpose is to supress warnings about unknown functions and types. Users who wish to suppress these warnings can invoke Dialyzer using this flag. Example: ```bash dialyzer module.erl -Wno_unknown ```
…wn-enabled-by-default/GH-5695/OTP-18439 dialyzer: make -Wunknown a default; add -Wno_unknown flag OTP-18439
I've found myself explicitly switching on
-Wunknown
in various places, and being confused when I've forgotten to set it and therefore not had Dialyzer warn when I expected it to. I started to wonder why it's not on by default, because I find it quite useful. My best guess is that it's off by default to allow people to run Dialyzer over a subset of their codebase for performance reasons, and doing this would potentially then result inunknown
warnings purely due to "missing" functions/modules being outside the set of things under analysis.From the docs:
What's the official view on why
unknown
warnings aren't always returned, and does it still make sense for this to be the case?The text was updated successfully, but these errors were encountered: