The test 'proper' takes some time.

A bug is fixed, but there are more problems.

Modify erl_types.erl like this:

  -define(EXPAND_LIMIT, 500).

and bogus warnings are output (again).

Callbacks and specs are compared (subtype) in dialyzer_behaviour. If
they are expanded to different depths, then invalid warnings can be
generated.

Using the new type syntax, we can specify which keys are required, and
which are optional in a way Dialyzer could use.

The type of a map is represented as a three-tuple {Pairs, DefaultKey,
DefaultValue}. DefaultKey and DefaultValue are types. Pairs is a list of
three-tuples {Key, mandatory | optional, Value}, where Key and Value are
types. All types Key must be singleton, or "known at compile time," as
the EEP put it. Examples:

    #{integer()=>list()}       {[], integer(), list()}
    #{a=>char(), b=>atom()}    {[{a, optional, char()},
                                 {b, optional, atom()}],
                                none(), none()}
    map()                      {[], any(), any()}

A more formal description of the representation and its invariants can
be found in erl_types.erl

Special thanks to Daniel S. McCain (@dsmccain) that co-authored a very
early version of this with me back in April 2014, although only the
singleton type logic remains from that version.

Parameterized modules are no longer supported, so module() can only be
an atom().

Background
-----------
In record fields with a type declaration but without an initializer, the
Erlang parser inserted automatically the singleton type 'undefined' to
the list of declared types, if that value was not present there.
I.e. the record declaration:

   -record(rec, {f1      :: float(),
                 f2 = 42 :: integer(),
                 f3      :: some_mod:some_typ()}).

was translated by the parser to:

   -record(rec, {f1      :: float() | 'undefined',
                 f2 = 42 :: integer(),
                 f3      :: some_mod:some_typ() | 'undefined'}).

The rationale for this was that creation of a "dummy" #rec{} record
should not result in a warning from dialyzer that e.g. the implicit
initialization of the #rec.f1 field violates its type declaration.

Problems
---------
This seemingly innocent action has some unforeseen consequences.

For starters, there is no way for programmers to declare that e.g. only
floats make sense for the f1 field of #rec{} records when there is no
`obvious' default initializer for this field. (This also affects tools
like PropEr that use these declarations produced by the Erlang parser to
generate random instances of records for testing purposes.)

It also means that dialyzer does not warn if e.g. an is_atom/1 test or
something more exotic like an atom_to_list/1 call is performed on the
value of the f1 field.

Similarly, there is no way to extend dialyzer to warn if it finds record
constructions where f1 is not initialized to some float.

Last but not least, it is semantically problematic when the type of the
field is an opaque type: creating a union of an opaque and a structured
type is very problematic for analysis because it fundamentally breaks
the opacity of the term at that point.

Change
-------
To solve these problems the parser will not automatically insert the
'undefined' value anymore; instead the user has the option to choose the
places where this value makes sense (for the field) and where it does
not and insert the | 'undefined' there manually.

Consequences of this change
----------------------------
This change means that dialyzer will issue a warning for all places
where records with uninitialized fields are created and those fields have
a declared type that is incompatible with 'undefined' (e.g. float()).
This warning can be suppressed easily by adding | 'undefined' to the
type of this field.  This also adds documentation that the user really
intends to create records where this field is uninitialized.

After introducing maps for supervisor flags and child specs two tests
in behaviour_SUITE started failing:

behaviour_SUITE:custom_sup - failed because the type of the Period
(MaxT) property had been changed (corrected) from non_neg_integer() to
pos_integer() in the specification of the init callback in
supervisor.erl

behaviour_SUITE:supervisor_incorrect_return - same as above, plus the
introduction of #{} as possible value for the supervisor flags and
child_specs.