[erlang-questions] Dialyzer bugs help

Anthony Ramine n.oxyde@REDACTED
Thu Jan 2 22:09:04 CET 2014


Hello Sean,

Replied inline.

Regards,

-- 
Anthony Ramine

Le 2 janv. 2014 à 20:26, Sean Cribbs <seancribbs@REDACTED> a écrit :

> Hi,
> 
> I'm trying to use dialyzer to remove a few typing bugs from neotoma (github.com/seancribbs/neotoma/tree/dialyzer) so that generated parsers will not contain them. However, I've hit a wall and need some help, I'm hoping someone here will be able to interpret these better than me (see also https://gist.github.com/seancribbs/8210317):
> 
>   Checking whether the PLT neotoma.plt is up-to-date... yes
>   Proceeding with analysis...
> peg_includes.hrl:85: The created fun has no local return
> peg_includes.hrl:86: Fun application will fail since P :: none() is not a function of arity 2
> peg_includes.hrl:201: The created fun has no local return

Still fighting these two.

> neotoma.erl:52: Guard test not(is_atom(ModName::atom())) can never succeed

In file/2 line 31, you pass ModuleName to atom_to_list:

    OutputFilename = filename:join(OutputDir, atom_to_list(ModuleName) ++ ".erl"),

You then pass that it validate_params/4:

    validate_params(filename:absname(InputGrammar),
                    ModuleName,
                    TransformModule,
                    filename:absname(OutputFilename)),

After line 31, Dialyzer knows ModuleName can’t be anything but an atom.

> neotoma.erl:124: Function bootstrap/0 has no local return

In bootstrap/0, you use an option ‘neotoma_priv_dir’ which isn’t in type option().

>  done in 0m2.41s
> done (warnings were emitted)
> 
> 
> The weird thing is, the variable P on peg_includes.hrl:86 is a known type, but something is causing it to think the type cannot be resolved.
> 
> Here's the function in question (the positive lookahead combinator):
> 
> -spec p_assert(parse_fun()) -> parse_fun().
> p_assert(P) ->
>   fun(Input,Index) ->
>       case P(Input,Index) of
>         {fail,_} = Failure-> Failure;
>         _ -> {[], Input, Index}
>       end
>   end.
> 
> Interestingly, that combinator is not called by anything in the parser in question (a separate issue to be resolved).
> 
> Thanks in advance,
> 
> Sean Cribbs
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions




More information about the erlang-questions mailing list