Dialyzer: report call to undefined function

[Vlad Dumitrescu]

Thanks for the reply!

I'm thinking ahead for things to integrate into Erlide (probably was
obvious? :-) and would very much like to be able to use as much "stock
code" as possible, because we have already patched versions of the
scanner, parser and syntax_tools. I don't feel very comfortable having
to maintain more and more variants of OTP code.

I'll keep in mind what you said, and when Dialyzer integration will
become the current feature to implement, I'll get back to check if
your patches made it to the release or if you could consider sharing
them.

best regards,
Vlad



On 5/19/06, Ulf Wiger (AL/EAB) <ulf.wiger@REDACTED> wrote:
>
> Vlad Dumitrescu wrote:
> >
> > I think it would be useful if Dialyzer would also report
> > calls to undefined or unexported functions. I often spell
> > names wrong :-)
>
> Agreed. Our local patched version of Dialyzer does this.
>
> I think the initial assumption was that there are other
> tools that do this for you, but we felt that since Dialyzer
> has the information, it might as well present it.
>
>
> > [Aside] How difficult would it be to make Dialyzer work
> > incrementally?
>
> Difficult - alas.
> We played with this quite a lot, since we have lots and lots
> of erlang code in a fairly slow version control system.
> Running Dialyzer on the ClearCase repository took about an
> hour per subsystem...
>
> What we did was to prune the PLT, removing all modules
> that depended on the ones being analysed.
>
> But the approach that finally became useful was to incorporate
> Dialyzer in our simulated environment, and running it on all
> code currently loaded (we use -embedded code loading). This,
> together with some optimizations in the call graph etc.,
> brought the time for a full system analysis down to 3 minutes
> (running in the background). Fredrik Svahn, one of our
> section managers, did some really good work there.
>
> > I mean that it should be possible to build the internal
> > tables by adding and removing modules from them, without
> > having to reread everything else. The analysis needs a global
> > approach, but for a large project, reading the files takes
> > the large chunk of the time.
>
> There are some pitfalls, though, and there is also the risk
> that incremental analysis will give a false sense of security.
>
> /Ulf (speaking as one who spent significant time trying to
> muscle in incremental analysis into Dialyzer. ;-)
>