comp.lang.ada
 help / color / mirror / Atom feed
From: Optikos <optikos@verizon.net>
Subject: Re: Referring to the instance of a generic parent package
Date: Thu, 24 Oct 2019 09:26:36 -0700 (PDT)
Date: 2019-10-24T09:26:36-07:00	[thread overview]
Message-ID: <2190c00e-6d8e-4659-a2de-a78861596e0b@googlegroups.com> (raw)
In-Reply-To: <qorr9n$a4o$1@dont-email.me>

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.

      reply	other threads:[~2019-10-24 16:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23 12:54 Referring to the instance of a generic parent package Alejandro R. Mosteo
2019-10-23 15:55 ` Jeffrey R. Carter
2019-10-24  9:42   ` Alejandro R. Mosteo
2019-10-23 16:29 ` Shark8
2019-10-24  9:35   ` Alejandro R. Mosteo
2019-10-24 16:26     ` Optikos [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox