Type of nested map creation expression is not inferred correctly

[erszcz]

@eksperimental in esl/gradient#30 reports an interesting bug, which I minimised to the following Elixir example:

iex(3)> Gradient.type_check_file("_build/dev/lib/beam_langs_meta_data/ebin/Elixir.Test.beam")
lib/test.ex: The map on line 10 is expected to have type %{required(:inner) => %{required(:a) => 5}} but it has type %{required(:inner) => %{optional(:a) => 5}}
8   @spec g :: %{inner: %{a: 5}}
9   def g do
10     %{inner: %{a: 5}}
11  end

iex(1)> Gradient.Debug.print_erlang(Test)
-module('Elixir.Test').

-spec g() -> #{inner := #{a := 5}}.
g() -> #{inner => #{a => 5}}.

It seems that nested map creation expressions don't get their type inferred properly, i.e. the associations are inferred as optional, whereas after map creation we know they must be present in the resulting map, therefore they should be inferred as required. One idea is that we might need some recursion in update_map_type, but this has to be confirmed.

[zuiderkwast]

I didn't think there would be any inference happening here, but now I see that there's actually some inference happening.

In to_type_check_expr_in we have a type ResTy (the map type from the spec) and an expression which is checked against this type.

The problem with inferring the type of the map expression and then checking if it's a subtype of the expected type is that the map expression can contain any kind of expression below it. It'd be better if we can call type_check_expr_in recursively on the map keys and values against their corresponding key and value types.