Referring to the instance of a generic parent package

Referring to the instance of a generic parent package

[Alejandro R. Mosteo]

I have the following situation:

    generic
    package Parent is ... end Parent;

    generic
       with package P is new Parent (<>);
    package Sibling is ... end Sibling;

    generic
    package Parent.Child is

       package A_Sibling is new Sibling (Parent);
       --  Works in GNAT CE 2019
       --  Error in FSF 7.4:
       --    "Expect package instance to instantiate formal"

    end Parent.Child

Now, since CE is more recent, I guess that's the correct one. Still, this 
made me think about name resolution inside a generic child. My guess is 
that actual instances take precedence, since a non-instance one can be 
prefixed with standard:

    generic
    package Parent.Child

       Standard.Parent -- Refers to the non-instance
       Parent          -- Refers to the parent instance

    end Parent.Child;

My cursory searching to look for relevant rules has been unsuccessful, I 
guess because I'm not finding the proper keywords. Assuming the above 
assumption is correct, I would like to make the initial hierarchy work in 
the FSF version too. I can of course make Child a non-child of Parent and 
also receive Parent as a generic formal. The question is, would there be 
another way of referring to a child's parent instance from the child? I 
tried this:

    generic
    package Parent.Child is

       package Renamed_Parent renames Parent;
       -- Works in FSF, but I guess that's not using the instance because:

       package A_Sibling is new Sibling (Renamed_Parent);
       -- Error: "actual parameter must be instance of Parent"

The whole issue is not critical; I'm just generally curious. I'm 
experimenting with heavily nested generic child hierarchies and finding 
lots of corner cases (and visibility bugs).

Cheers,
Álex.

Re: Referring to the instance of a generic parent package

[Jeffrey R. Carter]

On 10/23/19 2:54 PM, Alejandro R. Mosteo wrote:
> I have the following situation:
> 
>     generic
>     package Parent is ... end Parent;
> 
>     generic
>        with package P is new Parent (<>);
>     package Sibling is ... end Sibling;
> 
>     generic
>     package Parent.Child is
> 
>        package A_Sibling is new Sibling (Parent);
>        --  Works in GNAT CE 2019
>        --  Error in FSF 7.4:
>        --    "Expect package instance to instantiate formal"
> 
>     end Parent.Child

GNAT 9.1.0 also gives this error.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail
01

Re: Referring to the instance of a generic parent package

[Alejandro R. Mosteo]

On 23/10/19 17:55, Jeffrey R. Carter wrote:
> On 10/23/19 2:54 PM, Alejandro R. Mosteo wrote:
>> I have the following situation:
>>
>>     generic
>>     package Parent is ... end Parent;
>>
>>     generic
>>        with package P is new Parent (<>);
>>     package Sibling is ... end Sibling;
>>
>>     generic
>>     package Parent.Child is
>>
>>        package A_Sibling is new Sibling (Parent);
>>        --  Works in GNAT CE 2019
>>        --  Error in FSF 7.4:
>>        --    "Expect package instance to instantiate formal"
>>
>>     end Parent.Child
> 
> GNAT 9.1.0 also gives this error.

Thanks for the data point.

Re: Referring to the instance of a generic parent package

[Shark8]

On Wednesday, October 23, 2019 at 6:54:41 AM UTC-6, Alejandro R. Mosteo wrote:
> 
> The whole issue is not critical; I'm just generally curious. I'm 
> experimenting with heavily nested generic child hierarchies and finding 
> lots of corner cases (and visibility bugs).

Thank you for the efforts, please write up an Ada Issue (AI) for the problems you encounter so that the ARG can fix them.

Thank you.

Re: Referring to the instance of a generic parent package

[Alejandro R. Mosteo]

On 23/10/19 18:29, Shark8 wrote:
> On Wednesday, October 23, 2019 at 6:54:41 AM UTC-6, Alejandro R. Mosteo wrote:
>>
>> The whole issue is not critical; I'm just generally curious. I'm
>> experimenting with heavily nested generic child hierarchies and finding
>> lots of corner cases (and visibility bugs).
> 
> Thank you for the efforts, please write up an Ada Issue (AI) for the problems you encounter so that the ARG can fix them.

I meant in GNAT... I guess Ada itself is correct. The problem with these 
issues is that they disappear when I try to prepare a small reproducer.

Re: Referring to the instance of a generic parent package

[Optikos]

On Thursday, October 24, 2019 at 4:35:53 AM UTC-5, Alejandro R. Mosteo wrote:
> On 23/10/19 18:29, Shark8 wrote:
> > On Wednesday, October 23, 2019 at 6:54:41 AM UTC-6, Alejandro R. Mosteo wrote:
> >>
> >> The whole issue is not critical; I'm just generally curious. I'm
> >> experimenting with heavily nested generic child hierarchies and finding
> >> lots of corner cases (and visibility bugs).
> > 
> > Thank you for the efforts, please write up an Ada Issue (AI) for the problems you encounter so that the ARG can fix them.
> 
> I meant in GNAT... I guess Ada itself is correct. The problem with these 
> issues is that they disappear when I try to prepare a small reproducer.

Then don't start from scratch additively.  Instead prepare this subtractively instead:
1) change all the identifier names to something meaningless like v1, v2, v3, … for variables and t1, t2, t3, … for types to obfuscate what you'd prefer to not release publicly
then
2) loop
2.1) Remove one seemingly-extraneous statement.
2.2) Recompile to see whether the aberrant compiler behavior is still exhibited.
2.3) If so, repeat this loop with a different seemingly-extraneous statement.
2.4) If not, then put that seemingly-extraneous statement back in because it was not extraneous after all, but in fact sympathetic to contributing to the concomitant situation that evokes the bug in the compiler.  Then repeat this loop with a different seemingly-extraneous statement.

When no more seemingly-extraneous statements remain, you will have subtractively pruned your aberrant source code down to the minimum that it takes to put the compiler into its troubled internal state (e.g., just the right branches of the AST to cause a buggy walk of the AST to mishandle something).  Hopefully, between the renaming of identifiers en masse and the repeated incremental pruning, nothing human-recognizable will remain about the design that you'd prefer to not be made public.  Then submit the fully-pruned resulting source code to both FSF and AdaCore for the versions at which the aberrant compiler behavior is exhibited.

And additionally, please report back to c.l.a if there is a discernible pattern of FSF GNAT perennially having a bug that AdaCore GPL CommunityEdition perennially lacks, or a discernible delay of FSF GNAT having a bug for “too long” (that is eventually fixed in FSF GNAT) after being fixed in a release of AdaCore GPL CommunityEdition multiple years prior.  Either of those temporal situations would be interesting to observe if either were to exist.