yes another gnat bug (inherited tagged type as record field is too much for gnat??)

[gerrshapovalov@gmail.com]

Hello,

This bug gets triggered while trying to use a tiny "list library", that provides a uniform interface for an indexed/iterable storage a-la Ada.Containers.Vectors, that can be implemented in various ways: using A.C.Vecotrs internally or even plain "fixed" or "bounded" arrays..

This "library" is a part of ada_composition demo, now made into a stnandalone library, with tests as separate package, and can be found here:
https://github.com/gerr135/ada_composition

The lib itself is under ada_lists
and tests for the lib are under ada_lists_tests


Everything works just fine,.. - as long as I use these lists as "plain variables". However when such list is uses as a record field, gnat just commits suicide trying to compile it. 

Basically:

with Lists.Fixed;

package PL  is new Lists(Natural, Positive);
package PLF is new PL.Fixed;

LS : PLF.List(5);

type FRec (N : Positive) is record
    f : PLF.List(N);
end record;

LC : FRec(5);


LS(1)   := 1; -- works fine
LC.f(1) := 1; -- triggers gnat bug

+===========================GNAT BUG DETECTED==============================+
| Community 2019 (20190517-83) (x86_64-pc-linux-gnu) Storage_Error stack overflow or erroneous memory access

The code in the "library" is pretty much minimal (needed to implements indexed access and iteration), and the tests are just repeated blocks or basic code to test assignment and iteration (in the form of indexed and of loops).

So, the easiest way to reproduce this should be to just clone the project mentioned above ( https://github.com/gerr135/ada_composition )
and then:
cd ada_lists_tests
make

Quite "weirdly" the stock A.C.Vectors work fine as record fields. However, is this due to
1. them being "proper" types rather than descendants of some interface
2. some ACT black magic in their implementation (they do use locks and Unrestricted_Access) in the corresponding bodies, I looked)
is not quite clear to me..

Am I overlooking something here? 
This should be a really common use case, a very basic composition idea:
1. do all the algorithmic stuff at the "higher level", using abstract data accessor methods
2. Defer data storage and other implementation details to child packages..

Yes every time I am trying to do a very basic separation of this kind I trigger yet another gnat bug :(.