Version 1.7 of ai12s/ai12-0373-1.txt

Unformatted version of ai12s/ai12-0373-1.txt version 1.7
Other versions for file ai12s/ai12-0373-1.txt

!standard 3.1(1)          20-04-26 AI12-0373-1/05
!standard 4.2.1(3/5)
!standard 4.2.1(4/5)
!standard 4.2.1(5/5)
!standard 4.9(17.3/5)
!standard 6.1.1(41/5)
!standard 8.5.4(4/3)
!standard 13.1.1(4/3)
!standard 13.1.1(11/3)
!standard 13.14(3/5)
!class Amendment 20-03-22
!status Amendment 1-2012 20-03-22
!status work item 20-03-22
!status received 20-03-22
!priority Low
!difficulty Easy
!subject Bunch 'o fixes
!summary
[Editor's note: These fixes, while unapproved, are included in the draft 25 RM as they are not expected to be controversial.]
A number of fixes to the draft Ada 202x Standard are needed:
(1) The definition of statically names only excludes record components found in variants.
(2) Freezing of library units occurs at the end of the unit.
(3) Not all entities are (directly) associated with a declaration.
(4) User-defined literal functions can only have a single nonaliased "in" parameter.
(5) Missing "a" in 6.1.1(41/5).
(6) User-defined literals resolve as expected.
(7) Bit_Order is a representation aspect.
(8) Aggregate is a nonoverridable aspect.
(9) Remove the comma from 8.5.4(4/3).
!problem
(1) The definition of statically names excludes any discriminant-dependent component. The reason is to avoid any names that require a discriminant check. However, a discriminant-dependent array component does not require a discriminant check to name or read it. That means that this rule makes 'Old prefixes illegal that do not have to be illegal. We want to allow as many 'Old prefixes as possible, so this rule should be revised.
(2) AI12-0079-1 has been replaced by AI12-0079-3, but three Chapter 13 fixes didn't make the trip: a syntax rule allowing the special Global aspect syntax in aspect specifications; and two rules that are a general correction to explain when aspects of a library unit are evaluated/frozen.
(3) 3.1(1) says that an entity is introduced by a named declaration. That seems to imply that an array component is not an entity. That would make some things that are objects not entities.
(4) 4.2.1(3/5) says that the only parameter of a user-defined Integer_Literal function is of type String. But it doesn't specify a mode. Since the parameter is passed a string literal, a call to a function with a mode other than "in" would be illegal. Thus, defining the function with an "in out" parameter would be useless. Similarly, if the parameter was explicitly aliased, any call would be illegal as the actual is not aliased. So that would also be useless as well.
(5) 6.1.1(41/5) says "An implementation may evaluate known-on-entry subexpression of a postcondition expression...". Some word is missing here.
(6) 4.2(8/2) says that an Integer_Literal has type universal_integer. This doesn't seem to allow any way for a user-defined literal usage to resolve.
(7) The text defining attribute/aspect Bit_Order does not define the kind of aspect that it is. The usage of the aspect suggests that it is a representation aspect, and AARM 13.1(8.l) includes it in a list of representation aspects, but there needs to be something normative to this effect.
(8) 4.3.5(12/5) says that Aggregate is a nonoverridable aspect, but the list in 13.1.1(18.7/5) does not include Aggregate. One of these must be wrong.
(9) 8.5.4(4/3) says "The profile of a renaming-as-declaration shall be mode conformant, with that of the renamed callable entity." The comma here seems to be superfluous.
!proposal
(See Summary.)
!wording
Modify 3.1(1): [Item (3)]
The language defines several kinds of named entities that are declared by declarations. The entity's name is defined by the declaration, usually by a defining_identifier, but sometimes by a defining_character_literal or defining_operator_symbol. {[Redundant: There are also entities that are not directly declared; some of these are elements of other entities, or are allocated dynamically. Such entities can be denoted using indexed_component, selected_component, or dereference names (see 4.1).]}
AARM Discussion: Some entities are always anonymous. For instance, a type is never named (the name represents the first subtype). We don't mention those here as this paragraph is about named entities.
Modify 4.2(4.5): [Item (6)]
The expected type for a primary that is a string_literal shall be a single string type or a type with a specified String_Literal aspect (see 4.2.1). {In either case, the string_literal is interpreted to be of its expected type. If the expected type of an integer literal is a type with a specified Integer_Literal aspect (see 4.2.1), the literal is interpreted to be of its expected type; otherwise it is interpreted to be of type universal_integer. If the expected type of a real literal is a type with a specified Real_Literal aspect (see 4.2.1), it is interpreted to be of its expected type; otherwise, it is interpreted to be of type universal_real.}
Modify 4.2(8/2): [Item (6)]
[An integer literal is of type universal_integer. A real literal is of type universal_real. ]The literal null is of type universal_access.
Modify 4.2.1(3/5): [Item (4)]
This aspect is specified by a function_name that statically denotes a function with {a result type of T and} one {in} parameter {that is} of type String {and is not explicitly aliased}[ and a result type of T].
Modify 4.2.1(4/5): [Item (4)]
This aspect is specified by a function_name that statically denotes a function with {a result type of T and} one {in} parameter {that is} of type String {and is not explicitly aliased}[ and a result type of T].
Modify 4.2.1(5/5): [Item (4)]
This aspect is specified by a function_name that statically denotes a function with {a result type of T and} one {in} parameter {that is} of type Wide_Wide_String {and is not explicitly aliased}[ and a result type of T].
Modify 4.9(17.3/5): [Item (1)]
* is a selected_component whose prefix statically names an object, there is no implicit dereference of the prefix, and the selector_name [names a component that does not depend on a discriminant] {does not denote a component_declaration occurring within a variant_part}; or
Modify 6.1.1(41/5): [Item (5)]
An implementation may evaluate {a} known-on-entry subexpression of a postcondition expression of an entity at the place where X'Old constants are created for the entity, with the normal evaluation of the postcondition expression, or both.
Modify 8.5.4(4/3): [Item (9)]
The profile of a renaming-as-declaration shall be mode conformant[,] with that of the renamed callable entity.
Modify 13.1.1(4/3): [Item (2)]
aspect_definition ::= name | expression | identifier{ | global_aspect_definition}
Modify 13.1.1(11/3): [Item (2)]
The usage names in an aspect_definition [Redundant: are not resolved at the point of the associated declaration, but rather] are resolved at the end of the immediately enclosing declaration list{, or in the case of the declaration of a library unit, at the end of the visible part of the entity}.
Modify 13.1.1(18.7/5) to include aspect Aggregate. [Item (8)]
Modify 13.5.3(3): [Item (7)]
For every specific record subtype S, the following {representation } attribute is defined:
Modify 13.14(3/5): [Item (2)]
The end of a declarative_part, protected_body, or a declaration of a library package or generic library package, causes freezing of each entity and profile declared within it{, as well as the entity itself in the case of the declaration of a library unit}.
!discussion
(1) The reason for the rule is to prevent check failure for objects that are statically named. That's important for components found in a variant. However, simply accessing other kinds of discriminant-dependent components do not require any kind of check. Moreover, discriminant-dependent array components are not statically constrained, so their subcomponents cannot be statically named. Discriminant-dependent record components have the same requirements as any other record, so that's already covered.
Note that this makes statically name weaker than the rules for renaming; one can statically name a component that it is illegal to rename. For the major purposes of this term, however, we want the term to allow as much as possible (no sense in making illegal constructs which are not a problem), even if that is more than other similar constructs.
(2) Obviously, we need syntax rules that allow Global aspects.
The previous rules did not make a special case for library units. Since they technically occur in the declaration list of Standard, their aspects would not be frozen or evaluated until bind time. That means their values couldn't be used during their compilation or during the compilation of other units; any rule involving them would have to be treated as post-compilation rules. Similarly, the visibility would seem to allow private items to be used in the aspects. We want only visible entities, and we want the evaluation to occur no later than the end of the compilation unit (so they're part of the compilation of the unit). So we change the rules to ensure these happen.
(3) Clearly, objects are intended to be a subset of entities. There is plenty of wording that assumes that already in the Standard. For instance, 8.5(3) renaming says that a renaming elaborates the name to determine the entity. Since we can rename array subcomponents, clearly it's expected that they're entities.
Moreover, 4.1(11/2) says:
The evaluation of a name determines the entity denoted by the name...
So an entity is effectively anything that can be denoted by a name.
However, 3.1(1) is the only definition of entities in the Standard. We don't want to make it seem that a array component or type is not an entity simply because it doesn't have a declaration with a name. So we improve the wording to make it clear there are other kinds of entities.
(4) The equivalence of 4.2.1(7/5) ensures that no illegal call will be made. However, there is no reason to allow the definition of useless things, that almost certainly would be a bug, not something intended. So we enhance the requirements to require an "in" parameter and to prohibit explicitly aliased parameters.
(5) This is a simple typo. Inserting "a" fixes the wording.
(6) The Static Semantics equivalence of 4.2.1(7/5) defines all of the details of what happens to a legal expression that contains a user-defined literal. But it seems too much to have that modify resolution as well. Therefore, we modify the rules of 4.2 to make it clear how integer and real literals resolve.
(7) The usage of Bit_Order is clear that of a representation aspect, and the list of representation aspects in the AARM confirms it. Thus we add wording to clarify that Bit_Order is a representation aspect.
(8) It's pretty clear that 4.3.5(12/5) intentionally declares Aggregate as a nonoverridable aspect; the omission from the list of 13.1.1(18.7/5) is likely an oversight. Thus we correct this.
(9) The comma does not make sense in this sentence. This appears to have been an editing mistake when Ada 2012 removed various hyphens.
!corrigendum 3.1(1)
Replace the paragraph:
The language defines several kinds of named entities that are declared by declarations. The entity's name is defined by the declaration, usually by a defining_identifier, but sometimes by a defining_character_literal or defining_operator_symbol.
by:
The language defines several kinds of named entities that are declared by declarations. The entity's name is defined by the declaration, usually by a defining_identifier, but sometimes by a defining_character_literal or defining_operator_symbol. There are also entities that are not directly declared; some of these are elements of other entities, or are allocated dynamically. Such entities can be denoted using indexed_component, selected_component, or dereference names (see 4.1).
!corrigendum 4.2(4)
Replace the paragraph:
The expected type for a primary that is a string_literal shall be a single string type.
by:
The expected type for a primary that is a string_literal shall be a single string type or a type with a specified String_Literal aspect (see 4.2.1). In either case, the string_literal is interpreted to be of its expected type. If the expected type of an integer literal is a type with a specified Integer_Literal aspect (see 4.2.1), the literal is interpreted to be of its expected type; otherwise it is interpreted to be of type universal_integer. If the expected type of a real literal is a type with a specified Real_Literal aspect (see 4.2.1), it is interpreted to be of its expected type; otherwise, it is interpreted to be of type universal_real.
!corrigendum 4.2(8/2)
Replace the paragraph:
An integer literal is of type universal_integer. A real literal is of type universal_real. The literal null is of type universal_access.
by:
The literal null is of type universal_access.
!corrigendum 4.2.1(0)
Insert new clause:
The corrected text is found in the conflict file.
!corrigendum 4.9(17)
Insert after the paragraph:
the new paragraphs:
A name statically names an object if it:
For an entity other than an object, a name statically names an entity if the name statically denotes the entity.
!corrigendum 6.1.1(39/3)
Replace the paragraph:
For a call via an access-to-subprogram value, all precondition and postcondition checks performed are determined by the subprogram or entry denoted by the prefix of the Access attribute reference that produced the value.
by:
Implementation Permissions
An implementation may evaluate a known-on-entry subexpression of a postcondition expression of an entity at the place where X'Old constants are created for the entity, with the normal evaluation of the postcondition expression, or both.
!corrigendum 8.5.4(4/3)
Replace the paragraph:
The profile of a renaming-as-declaration shall be mode conformant, with that of the renamed callable entity.
by:
The profile of a renaming-as-declaration shall be mode conformant with that of the renamed callable entity.
!corrigendum 13.1.1(4/3)
Replace the paragraph:
aspect_definition ::= name | expression | identifier
by:

aspect_definition ::= 
    name | expression | identifier | aggregate | global_aspect_definition

!corrigendum 13.1.1(11/3)
Replace the paragraph:
The usage names in an aspect_definition are not resolved at the point of the associated declaration, but rather are resolved at the end of the immediately enclosing declaration list.
by:
The usage names in an aspect_definition are not resolved at the point of the associated declaration, but rather are resolved at the end of the immediately enclosing declaration list, or in the case of the declaration of a library unit, at the end of the visible part of the entity.
!corrigendum 13.14(3/5)
Replace the paragraph:
The end of a declarative_part, protected_body, or a declaration of a library package or generic library package, causes freezing of each entity and profile declared within it, except for incomplete types. A proper_body, body_stub, or entry_body causes freezing of each entity and profile declared before it within the same declarative_part that is not an incomplete type; it only causes freezing of an incomplete type if the body is within the immediate scope of the incomplete type.
by:
The end of a declarative_part, protected_body, or a declaration of a library package or generic library package, causes freezing of each entity and profile declared within it, as well as the entity itself in the case of the declaration of a library unit. A noninstance proper_body, body_stub, or entry_body causes freezing of each entity and profile declared before it within the same declarative_part.
!example
(1)
procedure Cutdown is type R (D : Positive) is record F : String (1 .. D); end record;
procedure P (X : in out R; Flag : Boolean) with Post => Flag or else X.F'Old <= X.F;
procedure P (X : in out R; Flag : Boolean) is begin null; end P; begin null; end Cutdown;
X.F'Old is illegal with the original rule, and legal with the rule as revised by this AI.
!ASIS
[Not sure. It seems like some new capabilities might be needed, but I didn't check - Editor.]
!ACATS test
ACATS B- and C-Tests are needed to check that the new capabilities are supported.
!appendix

From: Tucker Taft
Sent: Wednesday, March 18, 2020  9:54 AM

I just happened to notice that the earlier variant of the AI on the Global
aspect (AI12-0079-1) had some important additions to chapter 13:

Modify 13.1.1(4/3)

  aspect_definition ::= name | expression | identifier{
                      | global_aspect_definition}


Modify 13.1.1(11/3):

  The usage names in an aspect_definition [Redundant: are not resolved
  at the point of the associated declaration, but rather] are resolved
  at the end of the immediately enclosing declaration list{, or in the
  case of the declaration of a library unit, at the end of the visible
  part of the entity}.

Modify 13.14(3/5):

  The end of a declarative_part, protected_body, or a declaration of a
  library package or generic library package, causes freezing of each
  entity and profile declared within it{, as well as the entity itself
  in the case of the declaration of a library unit}.

-----

Since we have now adopted variant 3 of 0079, we should either move these 
chapter 13 changes to a separate AI, or simply include them in variant 3 as 
part of our "approve with changes" work.

****************************************************************

From: Randy Brukardt
Sent: Sunday, March 22, 2020  6:54 PM

I've put this into a "bunch of fixes" AI; it's a bit too much to do without 
some vote, and I don't want to reopen AI12-0079-3 lest people change their 
minds again. :-)

I'll check if there is anything else when I remove the old AI12-0079-1 from 
the draft RM and replace it with AI12-0079-3 (it should be obvious).

****************************************************************

From: Tucker Taft
Sent: Sunday, March 22, 2020  7:54 PM

> I've put this into a "bunch of fixes" AI; it's a bit too much to do 
> without some vote, and I don't want to reopen AI12-0079-3 lest people 
> change their minds again. :-)

Good plan.

> 
> I'll check if there is anything else when I remove the old AI12-0079-1 
> from the draft RM and replace it with AI12-0079-3 (it should be obvious).

OK, sounds good.

****************************************************************

Questions? Ask the ACAA Technical Agent