Version 1.6 of ai12s/ai12-0373-1.txt
!standard 3.1(1) 20-04-17 AI12-0373-1/04
!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 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.
!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.
!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 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.
!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:
- It denotes a renaming_declaration with a name that
statically denotes the renamed entity.
the new paragraphs:
A name statically names an object if it:
- statically denotes the declaration of an object (possibly
through one or more renames);
- is a selected_component whose prefix statically names an object,
there is no implicit dereference of the prefix, and the selector_name
does not denote a component_declaration occurring within a
variant_part; or
- is an indexed_component whose prefix statically names an object,
there is no implicit dereference of the prefix, the object is statically
constrained, and the index expressions of the object are static and have
values that are within the range of the index constraint.
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 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