[erlang-questions] incomplete union checks in dialyzer

[Tobias Lindahl]

2012/8/30 Motiejus Jakštys <desired.mta@REDACTED>

> On Thu, Aug 30, 2012 at 02:41:19PM +0200, Tobias Lindahl wrote:
> > 2012/8/30 Motiejus Jakštys <desired.mta@REDACTED>
> >
> > > On Thu, Aug 30, 2012 at 12:03 PM, Kostis Sagonas <kostis@REDACTED>
> > > wrote:
> > > > On 08/30/2012 11:53 AM, Motiejus Jakštys wrote:
> > > >>
> > > >> I wonder how hard would this be to encapsulate and add to dialyzer
> as
> > > >> a run-time option?
> > > >
> > > >
> > > > Very simple, I guess.
> > >
> > > Thanks again. I will look into that.
> > >
> > >
> > I'm not sure that this is a good idea. This set limit is controlling the
> > size of the inferred types, basically telling Dialyzer when to abstract
> > some types (i.e., 15 separate atoms will be collapsed into atom()). This
> is
> > of course affecting the fix point behavior of the analysis, as Kostis
> says,
> > which is fine.
> >
> > However, if the plt is built with one setting and the later analysis uses
> > another, I can imagine that you might end up in a situation where no fix
> > point can be found, yielding an infinite loop.
> >
> > Making this into a run time option indicates that it is something you can
> > play around with in order to get better results. To some extent it is,
> but
> > since it can have pretty serious implications it might not be a good
> idea.
>
> Hi,
> thanks for your comments.
>
> This is a good point. PLT and dialyzer runtime should be compatible.
>
> How about making this an option for --build_plt? And always getting the
> value from PLT for analysis?
>
>
Sounds reasonable.



> Motiejus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120903/a3045a97/attachment.htm>