[erlang-bugs] illegal declaration of pertially defined record types in dialyzer, R14A

Nico Kruber <>
Tue Aug 31 16:03:38 CEST 2010

On Tuesday 31 August 2010 15:48:50 Kostis Sagonas wrote:
> Nico Kruber wrote:
> > here's the other bug I originally intendet to report:
> > 
> > I declare a remote type rec1:rec1() in the rec1 module,
> > a record rec2 in module rec2 along with a rec2:rec2() type.
> > 
> > If I use the rec2:rec2() type in a third module, i.e. rec3, dialyzer
> > reports
> > an illegal declaration of rec2#{id}:
> There is probably something that needs improvement (or fine tuning) in
> dialyzer, but what you are doing below is totally unnecessary:
> -record(rec2, {id::rec1:rec1(), pid::pid()}).
> -type(rec2() :: #rec2{id::rec1:rec1(), pid::pid()}).
> Here you declare a typed record and in the next line you duplicate the
> declaration of the types of its fields.  There is no real reason to do
> this.
> Simply change the type declaration to the following equivalent one:
> -type(rec2() :: #rec{}).
> and the problem you reported will go away.

actually this is a minimal case - I use it a bit differently:

If I specify the type as you said, erlang will silently convert it to the 
following (as there are no initialisers in the record definition):

-type(rec2() :: #rec{id::'undefined | rec1:rec1(), pid::'undefined | pid()}).

as stated here:

We implemented a helper module to ease writing test suites. It parses those 
specs from the beam files and generates values from it.
The type I use now is defined opaque but every method in the according module 
gets well-formed records, i.e. no 'undefined' fields. I cannot provide useful 
initialisers though because we store pids, for example.
We not have to distinguish well-formed records and those that may be partially 
undefined and the given declaration would solve this problem.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100831/2c796f59/attachment.bin>

More information about the erlang-bugs mailing list