Re: GNAT or Language Problems?

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

"Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not> wrote in message 
news:u71gea$38ekv$1@dont-email.me...
> On 2023-06-22 11:51, Randy Brukardt wrote:
>> You missed my point: The requirement that the subtypes are statically
>> compatible was newly added. That applies to *all* subtypes, not just 
>> those
>> with predicates. The reason the requirement was added had to do with
>> predicates, but it might affect some marginal cases beyond that. It's a
>> weaker requirement than static matching, but stronger than no requirement 
>> at
>> all.
>>
>> As I said the other day, you need to check if 4.9.1 allows or disallows 
>> your
>> example (that's where the definition of static compatibility is found). 
>> If
>> it allows it, then it's a compiler bug, if it doesn't allow it, it's an
>> incompatibility with a language fix and you need to find a different way 
>> to
>> do whatever it is you are doing.
>
> Sorry, but I think you're wrong. The problem isn't static compatibility; 
> it's static matching. The error msg says the subtypes must statically 
> match, and the wording in 7.4(6/3) for deferred constants (which this is) 
> refers to statically matching constraints. So static compatibility doesn't 
> seem to be the issue.

Sigh. :Let's start over. My theory was that the problem came from an attempt 
by AdaCore to implement AI22-0041-1, a post Ada-2022 binding interpretation. 
That AI adds a static compatibility requirement to 7.4(6/3) (making it 
7.4(6/6)). (It of course could just be a bug, too, but AI22-0041-1 seems 
like the only sane reason to be changing the matching code in a working 
compiler that passes the ACATS.)

There is *no* version of the RM currently that includes the wording from 
post-Ada 2022 AIs (because of we had to wait for ISO to publish the thing 
first). You can only find that in the >50 approved AIs.

To save you the effort of looking up AI22-0041-1, here is the entire wording 
section from that AI:

Replace 7.4(6/3) :

  a.. If the deferred constant declaration includes a subtype_indication S 
that defines a constrained subtype, then the constraint defined by the 
subtype_indication in the full declaration shall match the constraint 
defined by S statically. [Redundant: On the other hand, if the subtype of 
the deferred constant is unconstrained, then the full declaration is still 
allowed to impose a constraint. The constant itself will be constrained, 
like all constants;]
with:

  a.. If the deferred constant declaration includes a subtype_indication 
that defines a subtype S1, then the subtype_indication in the full 
declaration shall define a subtype S2 that is statically compatible with S1 
(see 4.9.1). If S1 is a constrained subtype, the constraint defined by S2 
shall statically match the constraint defined by S1. [Redundant: If the 
subtype S1 of the deferred constant is unconstrained, then the full 
declaration is still allowed to impose a constraint.]
Modify 7.4(7/2):

  a.. If the deferred constant declaration contains the reserved word 
aliased, then the full declaration shall also{.}[;]
Delete 7.4(7.1/2) [now covered by static compatibility]:

  a.. If the subtype of the deferred constant declaration excludes null, 
then the subtype of the full declaration shall also exclude null.
Note that this adds a requirement for static compatibility of the subtypes 
for *all* deferred constant declarations. The AI also says that the separate 
static matching requirement is unnecessary; it was left alone to avoid 
making work for implementers in unlikely cases (it's weaker than static 
matching for scalar types, but deferred constants are rarely scalar).

Note that static compatibility requires static matching in some cases, so it 
could make sense to have the message say something about the types being 
required to match. (The distinction between "static compatibility" and 
"static matching" is lost on most people.)

                                  Randy.