From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE, XPRIO autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT or Language Problems? Date: Fri, 23 Jun 2023 04:55:15 -0500 Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Fri, 23 Jun 2023 09:55:07 -0000 (UTC) Injection-Info: dont-email.me; posting-host="838ba70884aabc9860d2ae2ba2a6d444"; logging-data="3889942"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19n7Stmblznw3IZDTrWMJ3Jn34JtNjAagg=" Cancel-Lock: sha1:plu+Bqs1V5ax4IwZri5ZfBFVbMM= X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-Priority: 3 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: news.eternal-september.org comp.lang.ada:65341 List-Id: "Jeffrey R.Carter" 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.