Built-in type struct is incorrectly defined

[margnus1]

The type of the struct built-in type is, as defined in lib/elixir/src/elixir.erl, #{'__struct__' => atom()}. This type does not match any struct values, however, as all structs contain keys that are not :__struct__, and as of OTP 19 Dialyzer is capable of recognising this, causing spurious warnings for Elixir projects that use the struct type.

A correct definition would be #{'__struct__' := atom(), atom() => any()}. If OTP 17&18 compatibility is required, the much weaker variant #{'__struct__' => atom(), atom() => any()} can be used, but I would implore the Elixir team to use version detection in order to get the stronger variant when compiled with OTP 19, as the weaker variant is almost indistinguishable from #{atom() => any()}.

The problematic type seems to have also propagated to Exception.t, causing one of the two test failures in Kernel.DialyzerTest, (number 4 as reported in #4851).

Environment

• Elixir version (elixir -v): 1.3.1 on OTP 19
• Operating system: GNU/Linux

Current behavior

Dialyzing the following module yields a dialyzer warning on good/0, but not on bad/0.

defmodule Repro do
    defstruct field: :default

    @spec good() :: struct
    def good() do
        %__MODULE__{}
    end

    @spec bad() :: struct
    def bad() do
        %{}
    end
end

Expected behavior

A dialyzer warning on bad/0, no warnings on good/0.

[whatyouhide]

I think we can have conditional type for structs based on the Erlang version. If there's agreement on this, I can look into implementing it.

[ericmj]

Thanks for the great report @margnus1.

[ericentin]

I'm going to try re-enabling some of those mentioned tests as well now.

[margnus1]

@ericmj You're welcome, but I believe you forgot to change the Exception.t type (lib/elixir/lib/exception.ex:18). @antipax will probably find that the particular test still fails.

[ericentin]

Yep, I fixed up that type and re-enabled the test, PR incoming.

[ericmj]

Should be fixed in 433ff88.

[ericmj]

@josevalim With the platform specific defines is there a chance an elixir build with OTP 19 will not work on OTP 18? Do we want this guarantee and have we followed it in the past? I think 19 itself is backwards compatible with 18 unless you use 19 specific features.