comcast / dialyzex

A Mix task for type-checking your Elixir project with dialyzer

dialyzex

This project adds a mix dialyzer task to your project. In addition to simply automating dialyzer for Elixir projects, it provides some features that existing solutions may not:

• Layered construction and validation of global PLTs for Erlang/OTP, Elixir, and a local PLT for project dependencies.
• Friendly ANSI-colored output.
• Exits non-zero when dialyzer produces warnings (good for continuous integration usage).
• Defaults to the strictest set of warnings available in Dialyzer, except for the few that are overly expensive.
• Ability to ignore acceptable warnings based on match patterns. For example, to ignore warnings produced by protocol compilation:

  # Ignore dialyzer warnings about compiler generated specs for Protocols
  {:warn_contract_supertype, :_, {:extra_range, [:_, :__protocol__, 1, :_, :_]}}

For more details, consult mix help dialyzer after installation.

Installation

dialyzex is available for installation from Hex. The package can be installed by adding dialyzex to your list of dependencies in mix.exs:

  def deps do
    [
      {:dialyzex, "~> 1.2.0", only: :dev}
    ]
  end

Documentation

Documentation is generated with ExDoc and published on HexDocs at https://hexdocs.pm/dialyzex.

Contributing

If you would like to contribute code to this project you can do so through GitHub by forking the repository and sending a pull request. Before Comcast merges your code into the project you must sign the Comcast Contributor License Agreement (CLA). If you haven't previously signed a Comcast CLA, you'll automatically be asked to when you open a pull request. Alternatively, we can e-mail you a PDF that you can sign and scan back to us. Please send us an e-mail or create a new GitHub issue to request a PDF version of the CLA.

Copyright & License

Copyright 2017 Comcast Cable Communications Management, LLC

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

This product includes software developed at Comcast (http://www.comcast.com/).

dialyzex's Issues

play nicely with dialyxir?

I've been using Dialyxir intensively for a while, but I'd like to give Dialyzex a try. Sadly, when I try to add them both as dependencies, all sorts of breakage ensue. Please try to find a way to let users install and use both of these packages. (See also: jeremyjh/dialyxir#348)

Add dialyzer.clean task

Adding the ability to rm all plts by running mix dialyzer.clean would be very useful, especially in CI environments.

This also keeps end users from having to know where dialyzex happens to place its plts for any given version (even though this is not likely to change).

Finally, if other mix dialyzer task-adding tools do the same, it creates a really nice API where you don't even have to know which tool you are using to purge plts. To that end I've duplicated this feature request here as well: jeremyjh/dialyxir#107.

Tag and publish a new version

v1.2.0 has been released a couple of years ago and in the meantime some changes have been made, it might be a good idea to tag a new release and publish it to hex.pm.

`mix dialyzer` fails to merge PLTs

Not sure why this is happening, wondering if you've seen it before?

Running analysis...
** (Mix) Could not merge PLTs since they are not disjoint
The following files are included in more than one PLTs:
["Elixir.Inspect.DateTime.beam"]

Error if no warnings are returned by dialyzer

I turned off underspecs to remove the noise from internal Elixir warnings on a new project and it causes the following error:

chris@anez % mix dialyzer --no-check
Running analysis...
** (FunctionClauseError) no function clause matching in Mix.Tasks.Dialyzer.format_results/1

    The following arguments were given to Mix.Tasks.Dialyzer.format_results/1:

        # 1
        []

    Attempted function clauses (showing 4 out of 4):

        defp format_results({[], []})
        defp format_results({ignored, []})
        defp format_results({[], failed})
        defp format_results({ignored, failed})

    lib/mix/tasks/dialyzer.ex:186: Mix.Tasks.Dialyzer.format_results/1
    lib/mix/tasks/dialyzer.ex:182: Mix.Tasks.Dialyzer.run/1
    (mix) lib/mix/task.ex:314: Mix.Task.run_task/3
    (mix) lib/mix/cli.ex:80: Mix.CLI.run_task/2
    (elixir) lib/code.ex:677: Code.require_file/2

I've put up a sample repo here that illustrates the issue:

https://github.com/chrismcg/diatest

Mix complains that dialyzer is not declared as a dependency of an application depending upon dialyzex

The deps.compile mix task in my Elixir Phoenix project that uses dialyzex complains with the following warnings:

==> dialyzex
Compiling 1 file (.ex)
warning: :dialyzer.format_warning/2 defined in application :dialyzer is used by the current application but the current application does not directly depend on :dialyzer. To fix this, you must do one of:

  1. If :dialyzer is part of Erlang/Elixir, you must include it under :extra_applications inside "def application" in your mix.exs

  2. If :dialyzer is a dependency, make sure it is listed under "def deps" in your mix.exs

  3. In case you don't want to add a requirement to :dialyzer, you may optionally skip this warning by adding [xref: [exclude: :dialyzer]] to your "def project" in mix.exs

  lib/mix/tasks/dialyzer.ex:399: Mix.Tasks.Dialyzer.format_warning/1

warning: :dialyzer.run/1 defined in application :dialyzer is used by the current application but the current application does not directly depend on :dialyzer. To fix this, you must do one of:

  1. If :dialyzer is part of Erlang/Elixir, you must include it under :extra_applications inside "def application" in your mix.exs

  2. If :dialyzer is a dependency, make sure it is listed under "def deps" in your mix.exs

  3. In case you don't want to add a requirement to :dialyzer, you may optionally skip this warning by adding [xref: [exclude: :dialyzer]] to your "def project" in mix.exs

  lib/mix/tasks/dialyzer.ex:255: Mix.Tasks.Dialyzer.dialyze/1

warning: Mix.Project.compile/1 is deprecated. Use Mix.Task.run("compile", args) instead
  lib/mix/tasks/dialyzer.ex:142: Mix.Tasks.Dialyzer.run/1

Generated dialyzex app

Since dialyzer is an indirect dependency, I should not have to declare it as a dependency of my application.

To reproduce,

1. Clone the repo https://github.com/aidalgol/dialyzex-dialyzer-dep-bug
2. Run mix do deps.get, deps.compile

This is a bare Phoenix template generated with phx_new 1.5.7 with the only change being to add {:dialyzex, "~> 1.2", only: :dev} to the deps definition in mix.exs.

My Elixir version is

$ elixir --version
Erlang/OTP 23 [erts-11.1.5] [source] [64-bit] [smp:32:32] [ds:32:32:10] [async-threads:1]

Elixir 1.11.2 (compiled with Erlang/OTP 23)

Incorporate Erlex?

Hi all.

I'm one of the maintainers of the Dialyxir project, and recently completed a large effort of brute force reverse engineering Dialyzer error messages and it resulted in new formatting of warnings here. The heavy lifting of this is done by a library I extracted called Erlex. May be worth incorporating some of this work into Dialyzex so that consumers have nicer messages.

Feel free to close this, but I can honestly say after having seen nicer Dialyzer output for the past few months, I refuse to go back to default Dialyzer output, and think consumers of your library would be very pleased with some of the improvements now possible.

Cheers,
Andrew

Ignore warning not happening

I'm trying to ignore a warning coming from phoenix's router:

          'error' can never match the type
          {#{'conn' := 'nil',
             'log' := 'debug',
             'path_params' := map(),
             'pipe_through' := [],
             'plug' :=
                 'Elixir.Router' |
                 'Elixir..Redirector',
             'plug_opts' := 'any' | [],
             'route' := <<_:8, _:_*128>>},
           fun((_, map()) -> any()),
           fun((_) -> any()),
           {'Elixir.Phoenix.Router.Route', {_, _, _}} |
           {'Elixir.Redirector', 'any'}}```

With `MIX_DEBUG` on:

```{:warn_matching, {'lib/phoenix/router.ex', 324},
   {:pattern_match,
    ['pattern \'error\'',
     '{\#{\'conn\':=\'nil\', \'log\':=\'debug\', \'path_params\':=map(), \'pipe_through\':=[]...

And here's what I have put in the project definition in my mix file:

dialyzer_ignored_warnings: [
        {:warn_matching, {"lib/phoenix/router.ex", :_}, {:pattern_match, :_}}
      ],

I'm sure that I've done something stupid, but I'm not seeing it.

Elixir 1.9.4
OTP 22
Phoenix 1.4.11

Add dialyzer.build task

Adding the ability to explicitly build the plts without running any dialyzer checks would be helpful for warming up caches in CI environments. This would be especially useful if your CI doesn't allow for configuring test task timeout but is more generous during the installation phase; or if it allows for extending task timeout but you want to know if for some reason your dialyzer checking time takes forever (independent of the plt build time).

It's also the logical inverse of the dialyzer.clean task proposed in #1, and I love symmetry.

This could also be called dialyzer.compile.

Alternately it could instead be registered under the compile namespace to allow this to occur automatically alongside other compilation tasks when mix compile is run, perhaps under the name compile.plts or compile.dialyzer. I'm inclined to avoid that though since that could unexpectedly make project compile times skyrocket in environments where dialyzer users aren't anticipating it.