type-checker: false positive

[ilya-klyuchnikov]

Elixir and Erlang/OTP versions

Erlang/OTP 28 [erts-16.3] [source] [64-bit] [smp:10:10] [ds:10:10:10] [async-threads:1] [jit] [dtrace]

Elixir 1.20.0-rc.3 (5979c42) (compiled with Erlang/OTP 28)

Operating system

MacOS

Current behavior

defmodule Bug do
    def foo(x, m) when not :erlang.map_get(x, m) do
        :ok
    end
end

    warning: incompatible types given to Kernel.not/1:

        not :erlang.map_get(x, m)

    given types:

        not boolean() or boolean()

    but expected one of:

        #1
        true

        #2
        false

    where "m" was given the type:

        # type: map()
        # from: bug.ex:2:36
        :erlang.map_get(x, m)

    type warning found at:
    │
  2 │     def foo(x, m) when not :erlang.map_get(x, m) do
    │                        ~
    │
    └─ bug.ex:2:24: Bug.foo/2

Expected behavior

No type error.

Bug.foo(:key, %{key: false}) is a valid input

[josevalim]

We changed how we approach guards in RC3 and it introduced some regressions. This is a similar one: #15198. We may need to rethink this.

[josevalim]

The issue here is that we cannot infer a reasonable type for m because x (the key) can be of any type. This happens because our maps only track literal keys for atoms, not any type.

For example, imagine you have this map:

map  = %{binary() => boolean() or integer()}

Even if you put:

Map.put(map, "some binary", true)

The following operation will still return type boolean() or integer():

Map.get(map, "some binary")

Because we don't track individual types in the map (except for atoms).

Therefore, a default map which has type %{term => term}, which is the case above, trying to access a key will always be interpreted as term.

If desired, we could solve this in the same we say solved #15198 but I am choosing not to do that for three reasons:

1. We don't expose :erlang.map_get in Elixir, only map.foo, which is an atom key and will be properly refined

2. The typing violation above will also happen once we add type signatures and %{x => v} returns anything but a boolean() (but it will work if you declare the value type as boolean)

3. It also works if you explicitly match on == true, which effectively forces the return given to not to be boolean

Thank you!

[josevalim]

@ilya-klyuchnikov I pushed a commit that documents these decisions in the test suite and stop splitting term types in error messages.