Re: Full view of limited extension?

["Randy Brukardt" <randy@rrsoftware.com>]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:5c6388d5-8545-4fa3-9c8c-228850e23028@googlegroups.com...
On Thursday, October 20, 2016 at 2:40:38 AM UTC+2, Randy Brukardt wrote:

>> > The "limited" keyword is already everywhere, there are no more places 
>> > to
>> > put it. :-) Am I missing some dark language corners here?
>>
>> There's clearly one more place to put it, since there existing a type
>> definition in the above code that doesn't include the word "limited". :-)
>
>In the full view? Sure. GNAT says:
>
>   "limited" keyword not allowed in private extension

That seems like a bug. But it seems unlikely. We made an ACATS test for this 
case (B730010) after it was reported, so it's unlikely that GNAT (or any 
current Ada 2005 compiler) would get it wrong. The objective is:

      Check that if the full_type_declaration for a private extension
      includes a derived_type_definition, then the reserved word limited
      shall appear in the full_type_declaration if it also appears in the
      private_extension_declaration.

This is testing RM 7.3(10.1/3), a rule that was added in Ada 2005.

>Without it we have:
>
>   full view of limited extension must be explicitly limited
>
>So it's both required and forbidden, at least according to *some* version 
>of GNAT.

So *some* version of GNAT has a bug? Wow, what a news flash. :-)

>I have to admit that I'm a bit tired of this, especially if checking the 
>code against different
>compiler versions hits additional problems related to gprbuild being or not 
>being available.
>Every compiler version that I tried has a different opinion on the code 
>that used to compile
>and work (!) properly in the past.

Sure, but the code was *never* legal Ada (2005 or later) code. It sometimes 
happens that an Ada compiler accidentally allows illegal Ada code, but once 
the compiler gets fixed, then such code no longer works. That's life, I'm 
afraid. Otherwise, no one could ever fix their compilers.

>This statement will not be popular on this group, but I have never had 
>similar problems with
>C++ - and we are talking about language features that are already at least 
>one decade old.
>Something went wrong somewhere.

Yes, your illegal code. :-) It was someone's attempt to port your code to a 
different Ada compiler (one that properly diagnosed the illegality) that 
caused (a) the ACATS test to be created, and (b) GNAT to be fixed [in some 
order].

The other thing that was wrong (IMHO) was that the ACATS was neglected 
during the Ada 2005 cycle, and many of these corner cases were not tested. 
Thus an error of omission (forgetting to enforce an error) can easily slip 
through. (I believe the #1 value of the ACATS is detecting errors of 
omission, since no other technique is very good at finding them. That way I 
find it so important that every Legality Rule in the Standard has an 
associated test - we're a long way from achieving that. And of course why 
ACATS B-Tests are so important, because without them the sort of portability 
problem you ran into would be much more prevalent.)

>I will keep trying, though.

Just remember that you've made Ada compilers better (and more consistent) by 
making this mistake. If you hadn't written that illegal code, it's likely 
that to omission in GNAT wouldn't have been detected for a number of more 
years. And it's the nature of this sort of bug that whomever detects it is 
going to be screwed. (We once had a similar sort of bug in Janus/Ada, where 
it wasn't necessary to "with System" before using it. Once we fixed the 
problem, we had recurring problems with previously working code failing to 
compile, requiring a detour to check out/fix/check in the unrelated but 
broken code before continuing.) It's unfortunate that you were the one who 
got the shaft here, but someone was going to get it sooner or later.

>Maciej Sobczak * http://www.inspirel.com

Randy Brukardt.