Help with Dialyzer Output

dialyzer
dialyxir

#1

I’m getting a few things from my dialyzer output that I’m not sure how I can fix.

:0:unknown_function
Function ExUnit.Assertions.flunk/1 does not exist.
________________________________________________________________________________
:0:unknown_function
Function ExUnit.Callbacks.__merge__/3 does not exist.
________________________________________________________________________________
:0:unknown_function
Function ExUnit.CaseTemplate.__proxy__/2 does not exist.

#2

I think adding ExUnit to plt_add_apps as described here in the readme https://github.com/jeremyjh/dialyxir#plt would get rid of the errors, but it is strange that the exunit functions are there to begin with…
Are you using ExUnit in your application code? Or maybe running with MIX_ENV=test?


#3

Yea I am running this on CI which is using the MIX_ENV=test, is it preferable to be running this on a different environment?


#4

I’m using:
dialyzer: [plt_add_deps: :transitive]


#5

You don’t really want to use transitive - thats just there for backwards compatibility. By default your app_tree is included in your deps, and since 1.4 Elixir has started your deps for you so they are all in your app tree. :ex_unit won’t be added though. If you want to dialyze in MIX_ENV=test you need to either add ignores for those lines, or add ex_unit separately using dialyzer: [plt_add_apps: [:ex_unit]]


#6

I think I can get CircleCI to run dialyzer with the dev environment so I can skip the whole plt_add_apps or ignore stuff. I’ve also removed the transitive option. I’ll give this a shot. Thanks guys


#7

If Circle runs on linux, it should totally be sufficient to use this line in the script:

MIX_ENV=dev mix dialyzer

Everything else will be run in test, but that line “overrides” the MIX_ENV temporary.


#8

@NobbZ awesome that worked.

Now I only have one real dialyzer error I need to fix. :tada:


#9

I’m stuck on a Dialyzer error (well, to be honest, most errors puzzle me) and could use some help. Here’s the code (the error is on the with line):

  defmacro __before_compile__(env) do
      ...
      for rule_group <- all_rule_sets do
        def unquote(rule_group)(number, locale_name) when is_binary(locale_name) do
          with {:ok, locale} <- unquote(backend).validate_locale(locale_name) do
            unquote(rule_group)(number, locale)
          end
        end
      end
    end
  end

And the error:

lib/number/rbnf/processor.ex:371:pattern_match
The pattern
{:ok, 95}

can never match the type
{:error, {atom(), binary()}}

Note that the function unquote(backend).validate_locale(locale_name) returns either {:ok, locale} or {:error, {exception, reason}}


#10

Hey @kip, did you ever get this figured out? If not, would it be possible to get a working example of this breaking in a small repo to look at?


#11

I didn’t get it worked out and just resorted to silencing the warning with an @dialyzer {:nowarn_function, ...}. I’ll see if I can distill this down to a much minimal reproducible example - it does bug me so some extra eyes would be much appreciated.


#12

I’m not exactly sure, but isn’t this just dialyzed way of telling you, that the else is missing?

Aside if that, there were issues with with and dialyzed in some elixir versions. So could you please tell us your elixir version?

Anyway, I think a repository to reproduce the issue would be nice.


#13

@NobbZ thats my working assumption. But I also assumed (perhaps naively) that dialyzer is working on the expanded code from with which does include the default clause in the generated case statement. I’ll create a minimalist case on a long flight on Thursday,


#14

Perhaps it might be enough if you just show the function that is called for the {:ok, 95} pattern. Perhaps dialzer thinks for some reason that that function can only return the error case?


#15

The function is:

      @spec validate_locale(Locale.locale_name() | LanguageTag.t()) ::
              {:ok, String.t()} | {:error, {module(), String.t()}}

      def validate_locale(%LanguageTag{cldr_locale_name: nil} = locale) do
        {:error, Locale.locale_error(locale)}
      end

      def validate_locale(%LanguageTag{} = language_tag) do
        {:ok, language_tag}
      end

      def validate_locale(locale_name) when is_binary(locale_name) do
        locale =
          locale_name
          |> String.downcase
          |> Cldr.Locale.locale_name_from_posix
          |> do_validate_locale

        case locale do
          {:error, {Cldr.UnknownLocaleError, _}} -> {:error, Locale.locale_error(locale_name)}
          {:error, reason} -> {:error, reason}
          locale -> locale
        end
      end

      def validate_locale(locale) do
        {:error, Locale.locale_error(locale)}
      end

Where locale -> locale is guaranteed to be {:ok, locale} -> {:ok, locale} (well, i believe its guaranteed).


#16

It probably goes down the rabbit hole into the do_validate_locale


#17

I know :slight_smile:

I’ve been down the rabbit hole several times and didn’t want to burden the forum with more. But since you asked … (and this is really bugging me!):

      for locale_name <- Cldr.Config.known_locale_names(config) do
        language_tag =
          Map.get(language_tags, locale_name)
          |> Cldr.Locale.put_gettext_locale_name(config)

        locale_name = String.downcase(locale_name)

        defp do_validate_locale(unquote(locale_name)) do
          {:ok, unquote(Macro.escape(language_tag))}
        end
      end

      # It's not a well known locale so we need to
      # parse and validate
      defp do_validate_locale(locale) do
        with {:ok, locale} <- Cldr.Locale.new(locale, unquote(backend)),
             true <- !is_nil(locale.cldr_locale_name) do
          {:ok, locale}
        else
          false -> {:error, Cldr.Locale.locale_error(locale)}
          {:error, reason} -> {:error, reason}
        end
      end

Which is, I think, the end of the rabbit hole!

For anyone who got this far - thanks for any ideas! And congratulations on your fortitude!


#18

What I’m wondering about is, that the pattern mentioned in the error is {:ok, 95}, But I can currently not find a path in the code that would generate that pattern anywhere…


#19

Blockquote

Does this have anything to do with the typespec saying it returns {:ok, String.t()} when in this case it’s actually {:ok, integer()}?


#20

Hmmmm, i was assuming the 95 was some kind of dialyzer reference not a literal. I cannot for the life of me see how a {:ok, 95} could be generated at all! Its just gets more puzzling.