[dialyzer] Fix handling of literal records

This ticket is about records in Erlang code, and when to check the
fields against the (optional) types given when defining records.

Dialyzer operates on the Erlang Core format, where there are no trace
of records. The fix implemented is a Real Hack:

Given the new option 'dialyzer' erl_expand_records marks the line
number of records in a way that is undone by v3_core, which in turn
inserts annotations that can be recognized by Dialyzer.

3 files changed, 59 insertions, 1 deletions

diff --git a/lib/dialyzer/test/small_SUITE_data/src/fun2ms.erl b/lib/dialyzer/test/small_SUITE_data/src/fun2ms.erl
new file mode 100644
index 0000000000..9e7df85e4c
--- /dev/null
+++ b/lib/dialyzer/test/small_SUITE_data/src/fun2ms.erl
@@ -0,0 +1,21 @@
+-module(fun2ms).
+-export([return/0]).
+-include_lib("stdlib/include/ms_transform.hrl").
+
+-record(snapshot, {id :: integer(), arg1 :: atom(), arg2 :: tuple()}).
+
+return() ->
+    TableId = ets:new(table, [public, {keypos, #snapshot.id}]),
+
+    ets:insert(TableId, [#snapshot{id = 1, arg1 = hard, arg2 = {1,2}},
+                         #snapshot{id = 2, arg1 = rock, arg2 = {1,2}},
+                         #snapshot{id = 3, arg1 = hallelujah, arg2 =
+                                       {1,2}}]),
+
+
+    Example = ets:fun2ms(
+                fun(#snapshot{id = Arg1, arg1 = Arg2}) ->
+                        {Arg1, Arg2}
+                end),
+
+    ets:select(TableId, Example).
diff --git a/lib/dialyzer/test/small_SUITE_data/src/literals.erl b/lib/dialyzer/test/small_SUITE_data/src/literals.erl
new file mode 100644
index 0000000000..abd7033712
--- /dev/null
+++ b/lib/dialyzer/test/small_SUITE_data/src/literals.erl
@@ -0,0 +1,33 @@
+-module(literals).
+
+%% Bad records inside structures used to be ignored. The reason:
+%% v3_core:unfold() does not annotate the parts of a literal.
+%% This example does not work perfectly yet, in particular Maps.
+
+-export([t1/0, t2/0, t3/0, t4/0, m1/1, m2/1, m3/1, m4/1]).
+
+-record(r, {id :: integer}).
+
+t1() ->
+    #r{id = a}. % violation
+
+t2() ->
+    [#r{id = a}]. % violation
+
+t3() ->
+    {#r{id = a}}. % violation
+
+t4() ->
+    #{a => #r{id = a}}. % violation found, but t4() returns... (bug)
+
+m1(#r{id = a}) -> % violation
+    ok.
+
+m2([#r{id = a}]) -> % violation
+    ok.
+
+m3({#r{id = a}}) -> % can never match; not so good
+    ok.
+
+m4(#{a := #r{id = a}}) -> % violation not found
+    ok.
diff --git a/lib/dialyzer/test/small_SUITE_data/src/confusing_record_warning.erl b/lib/dialyzer/test/small_SUITE_data/src/relevant_record_warning.erl
index 8af74e0914..3ff65458df 100644
--- a/lib/dialyzer/test/small_SUITE_data/src/confusing_record_warning.erl
+++ b/lib/dialyzer/test/small_SUITE_data/src/relevant_record_warning.erl
@@ -1,3 +1,7 @@
+%% Formerly confusing_record_warning.erl.
+%% The warning output is relevant as of Erlang/OTP 17.1.
+%% The original comment kept below.
+
 %%---------------------------------------------------------------------
 %% A user complained that dialyzer produces a weird warning for the
 %% following program.  I explained to him that there is an implicit
@@ -9,7 +13,7 @@
 %%    The pattern {'r', [_]} can never match the type any()
 %% We should clearly give some less confusing warning in this case.
 %%---------------------------------------------------------------------
--module(confusing_record_warning).
+-module(relevant_record_warning).
 
 -export([test/1]).