"Function call without opaqueness type mismatch" under OTP 28

Questions & Help Questions
,
1

With this code under OTP 27 dialyzer ran cleanly:

defmodule Test do
  @base_uribase_uri URI.new!(“`https://google.ca`”)

  def our_base do
    @base_uri |> URI.append_path(“/foo”)
  end
end

But in OTP 28 we are getting the following error:


> mix dialyzer
…

---

lib/app/test.ex:5:call_without_opaque
Function call without opaqueness type mismatch.

Call does not have expected term of type %URI{
:authority => URI.authority(),
:fragment => nil | binary(),
:host => nil | binary(),
:path => nil | binary(),
:port => nil | char(),
:query => nil | binary(),
:scheme => nil | binary(),
:userinfo => nil | binary()
} (with opaque subterms) in the 1st position.

URI.append_path(
%URI{
:authority => nil,
:fragment => nil,
:host => <<103, 111, 111, 103, 108, 101, 46, 99, 97>>,
:path => nil,
:port => 443,
:query => nil,
:scheme => <<104, 116, 116, 112, 115>>,
:userinfo => nil
},
<<47, 102, 111, 111>>
)
2

This looks like something to report to the elixir repo.

3

I think it should be fixed on the next 1.19rc: Mark inlined function call result as generated by sabiwara · Pull Request #14581 · elixir-lang/elixir · GitHub

4

OK I tried it out and it seems the error is still present on the v1.19 branch :cry:

Will open an issue.

Edit: issue link: Opaqueness warning on OTP28 · Issue #14750 · elixir-lang/elixir · GitHub

5

Thank you!

6

Hello,

Running into that tonight, and I’m not sure how to fix it without a dialyzer ignore.

I’m not sure I really understand the problem. Is dialyzer complaining that the given authority is not somehow inheriting the opaqueness? I tried to add nil which corresponds to the type, but I still have the error.

If I understand correctly, instead of this:

URI.to_string(%URI{scheme: scheme, host: host, port: port, authority: nil})

We should have something like this?:

URI.to_string(%URI{scheme: scheme, host: host, port: port, authority: URI.nil_authority()})

# module URI

@spec nil_authority :: authority
def nil_authority, do: nil

(When I say “we should” it’s only about making dialyzer happy again, I know it’s otherwise useless to specify the authority key to its default).

Currently my workaround is to use URI.parse which is more fragile because it involves string manipulation, or @dialyzer {:no_opaque, ...}. Is there a real proper solution to build URI structs from known data (scheme,host,etc)

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

Elixir 1.19.5 (compiled with Erlang/OTP 28)
7

For what it’s worth, we removed the opaqueness on authority (PR) on main/1.20rc but there hasn’t been a version after 1.19.5 to backport these changes.

So :no_opaque as a temporary stop-gap makes sense.

8

Thank you :slight_smile:

9

I’m wondering if I’m doing something wrong, b/c I’m still seeing errors in my project despite the related Elixir issues being closed as fixed. To test, I created a brand new mix project with this code

defmodule TmpDialyzerProject do
  @spec produce() :: MapSet.t(integer())
  def produce, do: MapSet.new([1, 2, 3])

  @spec consume(MapSet.t(integer())) :: list(integer())
  def consume(deleted) do
    MapSet.new([4, 5, 6])
    |> MapSet.difference(deleted)
    |> MapSet.to_list()
  end

  def driver, do: consume(produce())
end

and the result of mix dialyzer in Elixir 1.20.1 and OTP 28.4 is

lib/tmp_dialyzer_project.ex:12:27: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.

TmpDialyzerProject.consume(%MapSet{:map => %{1 => [], 2 => [], 3 => []}})

________________________________________________________________________________

Are folks still using the opaque exclusions, or is there something else I can do to resolve these?

10

Thanks for sharing @grossvogel. This issue is un-killable :zombie:

You’re not doing anything wrong. But unfortunately I fear we’re getting out of options here to deal with it in the language itself.

I managed to silence it using the following two workarounds:

def produce do
 # option 1: un-inline the MapSet creation so it's not a literal anymore
 list = [1, 2, 3])
 MapSet.new(list)
end

or

# option 2: replace produce/0 by a module attr
@produce MapSet.new([1, 2, 3])
def driver, do: consume(@produce)

But honestly it might be better to just explicitly disable opaqueness checks when working with MapSet rather than jumping through hoops and try to trick dialyzer.

11

OK, thanks for the help! I’ll go ahead and disable opaqueness checks

12

I’ve asked José in person 2 years ago on ElixirConfEU, if we could simply ditch opaque from MapSet declaration, and he answered “with new gradual types the issue’s gone.” It’s not.

I have a handful of MapSet helpers I use in each and every project, like mapset_size/1 guard and smart pattern-matching, and I always hesitate to add it because it enforces me to ignore dialyzer warnings which I dislike.

What’s indeed the issue with making a mapset implementation not opaque (besides it’s academically wrong :))?

13

Good question. I used to be optimistic as well but years later I think the only way to do it would be to vendor the implementation of :sets but just replace the signatures to not have opaque. Not a very enticing option either.

Because even after we removed the opaque from our own types and signatures, we’re still getting errors reported because dialyzer knows that the internals are calling :sets and the opaqueness propagates