OTP-26 dialyzer errors on reference to file:location() type

[mikpe]

Describe the bug
I have a module which implements a wrapper around the kernel's file:position/2 function. The wrapper function takes a Location so it's -spec uses file:location(). This compiles cleanly with OTP-25 and older, but with OTP-26 dialyzer generates a hard error: "Unknown type file:location/0", causing the build to fail.

The type is both defined and used in the file module documentation (https://www.erlang.org/doc/man/file.html) so I would have assumed it to be exported, but inspection of file.erl shows that it isn't, and never has been. Why earlier versions of dialyzer didn't flag this I don't know, perhaps defaults have changed, but the result is still a regression.

To Reproduce

> rebar3 new lib mylib
> cd mylib
> cat >> src/mylib.erl
-export([foo/2]).
-spec foo(file:io_device(), file:location()) -> ok.
foo(IoDev, Loc) ->
  {ok, _} = file:position(IoDev, Loc),
  ok.
^D

Compile and dialyze with OTP-25.3.2.3:

> rebar3 do compile,dialyzer
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling mylib
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling mylib
===> Dialyzer starting, this may take a while...
===> Updating plt...
===> Resolving project files...
===> Updating base plt...
===> Resolving base files...
===> Checking 206 files in /home/mikpe/.cache/rebar3/rebar3_25.3.2.3_plt...
===> Copying /home/mikpe/.cache/rebar3/rebar3_25.3.2.3_plt to /tmp/mylib/_build/default/rebar3_25.3.2.3_plt...
===> Checking 206 files in _build/default/rebar3_25.3.2.3_plt...
===> Doing success typing analysis...
===> Resolving project warning files...
===> Analyzing 1 files with _build/default/rebar3_25.3.2.3_plt...
> echo $?
0

Compile and dialyze with OTP-26.0.2:

> rm -rf _build
> rebar3 do compile,dialyzer
===> Failed to restore /home/mikpe/.cache/rebar3/plugins/.rebar3/rebar_compiler_erl/source_apps.dag file. Discarding it.

===> Analyzing applications...
===> Compiling hex_core
===> Compiling verl
===> Compiling rebar3_hex
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling mylib
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling mylib
===> Dialyzer starting, this may take a while...
===> Updating plt...
===> Resolving project files...
===> Updating base plt...
===> Resolving base files...
===> Checking 211 files in /home/mikpe/.cache/rebar3/rebar3_26.0.2_plt...
===> Copying /home/mikpe/.cache/rebar3/rebar3_26.0.2_plt to /tmp/mylib/_build/default/rebar3_26.0.2_plt...
===> Checking 211 files in _build/default/rebar3_26.0.2_plt...
===> Doing success typing analysis...
===> Resolving project warning files...
===> Analyzing 1 files with _build/default/rebar3_26.0.2_plt...

src/mylib.erl
Line 5 Column 29: Unknown type file:location/0
===> Warnings written to _build/default/26.0.2.dialyzer_warnings
===> Warnings occurred running dialyzer: 1
> echo $?
1

Expected behavior
I expected building with OTP-26 to succeed without errors or warnings, preferably by having file.erl export the previously non-exported type.

Affected versions
OTP-26.0.2.

Additional context
n/a

[garazdawi]

The type is both defined and used in the file module documentation (https://www.erlang.org/doc/man/file.html) so I would have assumed it to be exported, but inspection of file.erl shows that it isn't, and never has been. Why earlier versions of dialyzer didn't flag this I don't know, perhaps defaults have changed, but the result is still a regression.

In Erlang/OTP 26 we changed dialyzer to by default warn about missing types and functions. You can pass -Wno_unknown if you do not want these types of warnings. The warning was enabled by default to make sure users catch the type of errors that you have found. You can read more about it in OTP-18439.

The type section of the Erlang documentation can list both exported and un-exported types. At the moment there is no way to distinguish between the two without looking at the source code. The reason why we don't export all types that are documented is because some types are for documentation purposes only and should not be used by the user. That being said I think that file:location/0 falls into the category of types that should be exported.