MapSet.new/1 result triggers Dialyzer opaque type warning in Elixir 1.20.0-rc.5

[dkulchenko]

Existing issue

• I have searched existing issues and could not find a duplicate.

Elixir and Erlang/OTP versions

Primary repro:

Erlang/OTP 29 [erts-17.0] [source] [64-bit] [smp:28:28] [ds:28:28:10] [async-threads:1] [jit:ns]
Elixir 1.20.0-rc.5 (6050b84) (compiled with Erlang/OTP 29)

Also reproduces on OTP 28.5:

Erlang/OTP 28 [erts-16.4] [source] [64-bit] [smp:28:28] [ds:28:28:10] [async-threads:1] [jit:ns]
Elixir 1.20.0-rc.5 (6050b84) (compiled with Erlang/OTP 28)

Operating system

Debian 13 (Trixie)

Current behavior

A minimal function that creates a MapSet and immediately passes it to MapSet.member?/2 emits a Dialyzer opaque type warning on Elixir 1.20.0-rc.5.

Repro repo:

https://github.com/dkulchenko/mapset-dialyzer

Code:

defmodule Demo do
  def contains?(ids, id) do
    id_set = MapSet.new(ids)
    MapSet.member?(id_set, id)
  end
end

Steps:

git clone git@github.com:dkulchenko/mapset-dialyzer.git
cd mapset-dialyzer
mix deps.get
mix dialyzer

Dialyzer output:

lib/demo.ex:9:20:call_without_opaque
Function call without opaqueness type mismatch.

Call does not have expected term of type %MapSet{:map => :sets.set(_)} (with opaque subterms) in the 1st position.

MapSet.member?(_id_set :: %MapSet{:map => map()}, _id :: any())

This appears to be specific to Elixir 1.20 rather than Erlang/OTP 29. I verified:

Elixir 1.20.0-rc.5 / OTP 29 => reproduces
Elixir 1.20.0-rc.5 / OTP 28.5 => reproduces
Elixir 1.19.5 / OTP 28.5 => does not reproduce

Expected behavior

Dialyzer should accept the value returned by MapSet.new/1 as a valid MapSet.t() when passed to MapSet.member?/2, as it did on Elixir 1.19.5.

[josevalim]

Could this be a cache issue in your Dialyzer files? We no longer use opaque in MapSet: https://github.com/elixir-lang/elixir/blob/main/lib/elixir/lib/map_set.ex#L56

[josevalim]

Or perhaps Dialyzer is inferring from the usage of :sets that it is opaque? 🤔 Thoughts @sabiwara?

[sabiwara]

I was wondering the same 🤔 Looking into it.
Doesn't seem to be a cache issue, this is a new one indeed.
Seems any function using :sets would cause success typing to infer the type of :map to be an opaque set, disregarding our t() typespec.
It also impacts other functions such as union or difference.

[josevalim]

Unfortunately I do not believe we can generally fix the opaqueness issues since OTP28 as Elixir is in general not compatible with opaque types. Because of macros and module attributes, Elixir can inject the result of MapSet.new() in the code, which Dialyzer flags as violating opaqueness. We had many issues in the past about this and we decided to remove opaque types from Elixir: #15063. However, :sets themselves are opaque, and Erlang is now flagging those.

@sabiwara we need to choose our poison here. Maybe we should revert #15063 because at least that would one fail only if there was meta-programming? But now we are failing even for regular usage?

[sabiwara]

@sabiwara we need to choose our poison here. Maybe we should revert #15063 because at least that would one fail only if there was meta-programming? But now we are failing even for regular usage?

This was my thought as well, we could revert the inlining and put opaque back, but we'll still get warnings for module attributes...
Maybe that's the least worst option though.
And if you just need to check for membership on a fixed set, you don't need a set, you can inline a list: when foo in @my_list.
Will try to have a PR for this.

All that being said, it's still a bit sad to make compromises because of dialyzer given it should probably be less and less relevant for elixir as set theoretic types progress. But we could revisit this then I suppose.