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.
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?
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?
I’m using:
dialyzer: [plt_add_deps: :transitive]
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]]
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
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.
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}}
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?
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.
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.
@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,
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?
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).
It probably goes down the rabbit hole into the do_validate_locale
I know 
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!
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…
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()}?
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.
© Copyright Elixir Forum | Terms | Privacy & Cookies
