Generic oddness

Generic oddness

[Per Jakobsen]

Declaring the package List_Type from Doubly_Linked_Lists gives me "abstract subprogram not allowed as generic actual" unless I declare the "A_Intf" type in a package separate from the List_Type declaration, or if I instantiate a workaround (dummy) generic before (as in the below MWE):

--- gnatchop ---------------------
generic
   type A is private;
package Gen is
   pragma Pure;
end Gen;
package Intf is
   type Intf_Type is interface;
   procedure Do_Stuff (I : in out Intf_Type) is abstract;
end Intf;
with Ada.Containers.Doubly_Linked_Lists;
with Intf;
with Gen;

package Test is
   use Intf;

   type A_Intf is new Intf_Type with
      record
         A : Natural;
      end record;

   overriding
   procedure Do_Stuff (I : in out A_Intf);

   package Workaround is new Gen (A => A_Intf);
   --  Commenting the above line will cause the
   --  next line to fail !?!?
   package List_Type is
      new Ada.Containers.Doubly_Linked_Lists (Element_Type => A_Intf,
                                              "="          => "=");
end Test;
package body Test is

   overriding
   procedure Do_Stuff (I : in out A_Intf) is
   begin
      null;
   end Do_Stuff;

end Test;
--- gnatchop end ---------------------

Unpack with gnatchop, then compile with gnatmake test.adb. Then comment the Workaround package instantiation and recompile.

Using GNATMAKE Community 2019 (20190517-83).

Is there a sane explanation for this behavior?

~Per

Re: Generic oddness

[Ludovic Brenta]

Per Jakobsen <pdj@knaldgas.dk> writes:
> Declaring the package List_Type from Doubly_Linked_Lists gives me
> "abstract subprogram not allowed as generic actual" unless I declare
> the "A_Intf" type in a package separate from the List_Type
> declaration, or if I instantiate a workaround (dummy) generic before
> (as in the below MWE):
>
> --- gnatchop ---------------------
> generic
>    type A is private;
> package Gen is
>    pragma Pure;
> end Gen;
> package Intf is
>    type Intf_Type is interface;
>    procedure Do_Stuff (I : in out Intf_Type) is abstract;
> end Intf;
> with Ada.Containers.Doubly_Linked_Lists;
> with Intf;
> with Gen;
>
> package Test is
>    use Intf;
>
>    type A_Intf is new Intf_Type with
>       record
>          A : Natural;
>       end record;
>
>    overriding
>    procedure Do_Stuff (I : in out A_Intf);
>
>    package Workaround is new Gen (A => A_Intf);
>    --  Commenting the above line will cause the
>    --  next line to fail !?!?
>    package List_Type is
>       new Ada.Containers.Doubly_Linked_Lists (Element_Type => A_Intf,
>                                               "="          => "=");
> end Test;
> package body Test is
>
>    overriding
>    procedure Do_Stuff (I : in out A_Intf) is
>    begin
>       null;
>    end Do_Stuff;
>
> end Test;
> --- gnatchop end ---------------------
>
> Unpack with gnatchop, then compile with gnatmake test.adb. Then
> comment the Workaround package instantiation and recompile.
>
> Using GNATMAKE Community 2019 (20190517-83).
>
> Is there a sane explanation for this behavior?

I think I have a partial explanation.  Instantiating the package Gen
freezes the type Test.A_Intf.  Similarly, if you declare A_Intf in a
package and then instantiate Doubly_Linked_Lists in another package, the
instantiation of Doubly_Linked_Lists sees a frozen type as the actual.

The part that I don't understand is why you can instantiate Gen but not
Doubly_Linked_Lists with the same actual type as parameter; I think the
instantiation of Doubly_Linked_Lists should freeze the type A_Intf just
like package Workaround does.

-- 
Ludovic Brenta.
Multi-channel structures transfer the thinkers/planners throughout the
organization. In the same time, the enabler will be well equipped to
harness an alternative.

SOLVED: Generic oddness

[Per Jakobsen]

søndag den 12. april 2020 kl. 18.38.11 UTC+2 skrev Ludovic Brenta:
> 
> The part that I don't understand is why you can instantiate Gen but not
> Doubly_Linked_Lists with the same actual type as parameter; I think the
> instantiation of Doubly_Linked_Lists should freeze the type A_Intf just
> like package Workaround does.

I believe I've found the explanation:
A friend reminded me that our mutual friend Jacob Sparre Andersen actually reported this problem back in Sep 2017 (ticket: Q904-007) which was reported fixed in June 2019.

The problem is the equality function required for Doubly_Linked_List. If I add a similar function parameter to the Gen generic, it fails as well.

Apparently the implicitly declared equality operator for a type implementing an Interface is treated as abstract until the type is frozen, which can be done in several different ways.

Anyway it seems to be a problem that has been fixed in the recent compiler, soon to be released in the Community Edition.

~Per

Re: Generic oddness

[Simon Wright]

Per Jakobsen <pdj@knaldgas.dk> writes:

> Is there a sane explanation for this behavior?

Possibly not, because GCC 10.0.1 (admittedly of 20200206, so a while
ago) compiles without (much) complaint:

   $ /opt/gnat-ce-2019/bin/gnatmake -gnatwa -f test.adb
   gcc -c -gnatwa test.adb
   test.ads:3:06: warning: unit "Gen" is not referenced
   test.ads:21:63: abstract subprogram not allowed as generic actual
   gnatmake: "test.adb" compilation error

but

   $ /opt/gcc-10.0.1/bin/gnatmake -gnatwa -f test.adb
   gcc -c -gnatwa test.adb
   test.ads:3:06: warning: unit "Gen" is not referenced
   gcc -c -gnatwa gen.ads
   gen.ads:2:09: warning: type "A" is not referenced
   gcc -c -gnatwa intf.ads