Version 1.6 of ai12s/ai12-0417-1.txt

Unformatted version of ai12s/ai12-0417-1.txt version 1.6
Other versions for file ai12s/ai12-0417-1.txt

!standard 7.2(4)          21-03-02 AI12-0417-1/03
!standard 10.1.5(1)
!standard 10.1.5(2)
!standard 10.1.5(3)
!standard 10.1.5(4)
!standard 10.1.5(5/1)
!standard 10.1.5(6)
!standard 10.1.5(7/3)
!standard 10.1.5(7.1/1)
!standard 10.1.5(10/1)
!standard 10.2(15/3)
!standard 10.2(33)
!standard 10.2.1(1)
!standard 10.2.1(2)
!standard 10.2.1(3)
!standard 10.2.1(4)
!standard 10.2.1(10.1/3)
!standard 10.2.1(11/3)
!standard 10.2.1(13)
!standard 10.2.1(14)
!standard 10.2.1(15)
!standard 10.2.1(17/3)
!standard 10.2.1(19)
!standard 10.2.1(22)
!standard 10.2.1(24)
!standard 10.2.1(25/3)
!standard 10.2.1(26.1/3)
!standard 13.1(9.2/5)
!standard 13.1.1(32/4)
!standard C.4(1/3)
!standard E.1(15)
!standard E.2(2/3)
!standard E.2(3/3)
!standard E.2(14)
!standard E.2.1(2)
!standard E.2.1(3)
!standard E.2.1(4/3)
!standard E.2.2(2)
!standard E.2.2(3)
!standard E.2.2(4/3)
!standard E.2.3(2)
!standard E.2.3(3)
!standard E.2.3(4)
!standard E.2.3(5)
!standard E.2.3(6)
!standard E.2.3(7/3)
!standard E.2.3(16/3)
!standard E.2.3(20/3)
!standard J.15(1/3)
!standard J.15.14(0)
!standard J.15.15(0)
!class Amendment 20-12-08
!status Amendment 1-2012 21-01-21
!status ARG Approved 16-0-0 21-01-20
!status work item 20-12-08
!status received 20-09-29
!priority Low
!difficulty Easy
!subject Make categorization pragmas obsolescent
!summary
Obsolesce categorization pragmas, and make the aspects the primary definition.
!problem
Various AIs, culminating in AI12-0414-1, have replaced all categorization pragmas in the RM with categorization aspects. Ada 2012 already replaced and obsolesced most of the other pragmas that apply to entities.
However, the categorization pragmas are still defined as the primary definition of that concept. It's not obvious from the current wording that one can use these categorizations as aspects.
!proposal
(See Summary.)
!wording
Modify 7.2(4):
A package_body shall be the completion of a previous package_declaration or generic_package_declaration. A library package_declaration or library generic_package_declaration shall not have a body unless it requires a body; {the}[pragma] Elaborate_Body{ aspect} can be used to require a library_unit_declaration to have a body (see 10.2.1) if it would not otherwise require one.
Modify 10.1.5(1):
This subclause discusses pragmas related to [program units, library units, and ]compilations.
Delete 10.1.5(2) through 10.1.5(7.1/1). [These will move to J.15.]
Delete 10.1.5(10/1).
Modify 10.2(15/3):
Any included library_unit_declaration for which aspect Elaborate_Body is True [(including when a pragma Elaborate_Body applies)] is immediately followed by its library_unit_body, if included.
Modify 10.2(33):
An order of elaboration of library_items that is consistent with the partial ordering defined above does not always ensure that each library_unit_body is elaborated before any other compilation unit whose elaboration necessitates that the library_unit_body be already elaborated. (In particular, there is no requirement that the body of a library unit be elaborated as soon as possible after the library_unit_declaration is elaborated, unless the pragmas{ or aspects} in subclause 10.2.1 are used.)
Modify 10.2.1(1):
This subclause defines {aspects and }pragmas that help control the elaboration order of library_items.
[Editor's note: pragmas Elaborate and Elaborate_All remain in this clause.]
Delete 10.2.1(2-4). [The definition of pragma Preelaborate, now moved to Annex J.]
Modify 10.2.1(10.1/3):
* the actual for each discriminated formal derived type, formal private type,
or formal private extension declared within the formal part of the generic unit is a type that does not have preelaborable initialization, unless {the}[pragma] Preelaborable_Initialization {aspect was specified for}[has been applied to] the formal type;
[Editor's note: This is a paragraph that should have been modified by AI12-0409-1 that was not, which I discovered checking wording for left-over references to pragmas.]
Modify 10.2.1(11/3):
{When the library unit aspect (see 13.1.1) Preelaborate of a program unit is True, the}[A pragma Preelaborate (or pragma Pure — see below) is used to specify that a library] unit is {said to be} preelaborated[, namely that the Preelaborate aspect of the library unit is True;]{. When the Preelaborate aspect is specified True for a library unit,} all compilation units of the library unit are preelaborated. The declaration and body of a preelaborated library unit, and all subunits that are elaborated as part of elaborating the library unit, shall be preelaborable. All compilation units of a preelaborated library unit shall depend semantically only on declared pure or preelaborated library_items. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. If a library unit is preelaborated, then its declaration, if any, and body, if any, are elaborated prior to all nonpreelaborated library_items of the partition.
Add after AARM 10.2.1(11.a.1/1) (part of a Ramification):
If a unit is not preelaborated, the value of the Preelaborate aspect for that unit is False.
[Editor's note: I wanted to say somewhere what the meaning of Preelaborate being set False is; it follows from normal logic but that may not be obvious.]
Add after AARM 10.2.1(11.b/3):
Discussion: Rules for specifying a library unit aspect (like Preelaborate) are found in 13.1.1.
Delete 10.2.1(13-15). [The definition of pragma Pure, now moved to Annex J.]
Modify 10.2.1(17/3):
{When the library unit aspect Pure of a program unit is True, the} [A pragma Pure is used to specify that a library] unit is {said to be }declared pure[, namely that the Pure aspect of the library unit is True;]{. When the Pure aspect is specified True for a library unit,} all compilation units of the library unit are declared pure. In addition, the limited view of any library package is declared pure. The declaration and body of a declared pure library unit, and all subunits that are elaborated as part of elaborating the library unit, shall be pure. All compilation units of a declared pure library unit shall depend semantically only on declared pure library_items. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. Furthermore, the full view of any partial view declared in the visible part of a declared pure library unit that has any available stream attributes shall support external streaming (see 13.13.2).
Add after AARM 10.2.1(17.d.1/3) (part of a Ramification):
If a unit is not declared pure, the value of the Pure aspect for that unit is False.
Replace 10.2.1(19): The form of a pragma Elaborate, Elaborate_All, or Elaborate_Body is as follows: with: The following pragmas are defined with the given forms:
Delete 10.2.1(22).
Delete 10.2.1(24).
Modify 10.2.1(25/3):
If the aspect Elaborate_Body is True for a declaration [(including when pragma Elaborate_Body applies)], then the declaration requires a completion (a body).
Modify 10.2.1(26.1/3):
[A pragma Elaborate_Body sets the Elaborate_Body representation aspect of the library unit to which it applies to the value True. ]@Redundant[If the Elaborate_Body aspect of a library unit is True, the body of the library unit is elaborated immediately after its declaration.
Modify AARM 10.2.1(26.b):
The {specification}[presence] of [a pragma]{the} Elaborate_Body {aspect} simplifies the removal of unnecessary Elaboration_Checks. For a subprogram declared immediately within a library unit {for}[to] which {the}[a pragma] Elaborate_Body {aspect is specified as True}[applies], the only calls that can fail the Elaboration_Check are those that occur in the library unit itself, between the declaration and body of the called subprogram; if there are no such calls (which can easily be detected at compile time if there are no stubs), then no Elaboration_Checks are needed for that subprogram. The same is true for Elaboration_Checks on task activations and instantiations, and for library subprograms and generic units.
Change the cross-reference in 13.1(9.2/5) from 10.1.5 to J.15.
Modify 13.1.1(32/4):
{Some aspects are defined to be /library unit aspects/. Library unit aspects are}[Any aspect specified by a representation pragma or library unit pragma that has a local_name as its single argument may be specified by an aspect_specification, with the entity being the local_name. The aspect_definition is expected to be] of type Boolean. The expression {specifying a library unit aspect }shall be static. {Library unit aspects are defined for all program units, but shall be specified only for library units. }Notwithstanding what this International Standard says elsewhere, the expression of {a library unit}[an] aspect [that can be specified by a library unit pragma] is resolved and evaluated at the point where it occurs in the aspect_specification@Redundant[, rather than the first freezing point of the associated {unit}[package]].
[Editor's note: I've deleted the equivalence between pragmas and aspects. With this AI, all language-defined pragmas that have associated aspects already have such an equivalence defined explicitly. And implementation-defined pragmas can do whatever they want anyway. So this is just wasted text. I changed "package" to "unit" since library unit aspects can be given on subprograms.]
Modify C.4(1/3):
This subclause specifies additional implementation and documentation requirements for the Preelaborate {aspect}[pragma] (see 10.2.1).
Modify E.1(15):
Library units are grouped into partitions after compile time, but before run time. At compile time, only the relevant library unit properties are identified using categorization {aspects}[pragmas].
Modify E.2(2/3):
[A categorization pragma is a library unit pragma (see 10.1.5) that specifies a corresponding categorization aspect. ]A categorization aspect restricts the declarations, child units, or semantic dependences of the library unit to which it applies. A categorized library unit is a library unit that has a categorization aspect that is True.
Modify E.2(3/3):
The {aspects}[pragmas] Shared_Passive, Remote_Types, and Remote_Call_Interface [are categorization pragmas, and the associated aspects ]are categorization aspects. In addition, for the purposes of this Annex, the aspect Pure (see 10.2.1) is considered a categorization aspect[ and the pragma Pure is considered a categorization pragma].
Delete E.2(14). [Editor's Note: This paragraph was not moved to Annex J, as it is always the case that implementations can define pragmas, and those pragmas can do whatever they want. So this doesn't add anything.]
Delete E.2.1(2) and E.2.1(3).
Modify E.2.1(4/3):
{When the library unit aspect (see 13.1.1) Shared_Passive of a library unit is True, the}[A pragma Shared_Passive is used to specify that a] library unit is a /shared passive library unit/[, namely that the Shared_Passive aspect of the library unit is True]. The following restrictions apply to such a library unit:
Delete E.2.2(2) and E.2.2(3).
Modify E.2.2(4/3):
{When the library unit aspect (see 13.1.1) Remote_Types of a library unit is True, the}[A pragma Remote_Types is used to specify that a] library unit is a /remote types library unit/[, namely that the Remote_Types aspect of the library unit is True]. The following restrictions apply to such a library unit:
Delete E.2.3(2) through E.2.2(6).
Modify E.2.3(7/3):
{When the library unit aspect (see 13.1.1)}[A pragma] Remote_Call_Interface {of a library unit is True, the}[is used to specify that a] library unit is a /remote call interface (RCI)/[, namely that the Remote_Call_Interface aspect of the library unit is True]. A subprogram declared in the visible part of such a library unit, or declared by such a library unit, is called a /remote subprogram/.
Modify E.2.3(16/3):
[A pragma All_Calls_Remote sets the ]All_Calls_Remote {is a library unit}[representation] aspect[ of the library unit to which the pragma applies to the value True]. If the All_Calls_Remote aspect of a library unit is True, the library unit shall be a remote call interface.
Modify E.2.3(20/3):
An implementation need not support the Remote_Call_Interface [pragma or ]aspect nor the All_Calls_Remote {aspect}[pragma]. Explicit message-based communication between active partitions can be supported as an alternative to RPC.
Replace J.15 with (most of this is moved from 10.1.5):
J.15 Aspect-related Pragmas
Pragmas can be used as an alternative to aspect_specifications to specify certain aspects.
Name Resolution Rules
Certain pragmas are defined to be /program unit pragmas/. A name given as the argument of a program unit pragma shall resolve to denote the declarations or renamings of one or more program units that occur immediately within the declarative region or compilation in which the pragma immediately occurs, or it shall resolve to denote the declaration of the immediately enclosing program unit (if any); the pragma applies to the denoted program unit(s). If there are no names given as arguments, the pragma applies to the immediately enclosing program unit.
AARM Ramification: The fact that this is a Name Resolution Rule means that the pragma will not apply to declarations from outer declarative regions.
Legality Rules
A program unit pragma shall appear in one of these places:
* At the place of a compilation_unit, in which case the pragma shall immediately follow in the same compilation (except for other pragmas) a library_unit_declaration that is a subprogram_declaration, generic_subprogram_declaration, or generic_instantiation, and the pragma shall have an argument that is a name denoting that declaration.
AARM Ramification: The name has to denote the immediately preceding library_unit_declaration.
* Immediately within the visible part of a program unit and before any nested declaration (but not within a generic formal part), in which case the argument, if any, shall be a direct_name that denotes the immediately enclosing program unit declaration.
AARM Ramification: The argument is optional in this case.
* At the place of a declaration other than the first, of a declarative_part or program unit declaration, in which case the pragma shall have an argument, which shall be a direct_name that denotes one or more of the following (and nothing else): a subprogram_declaration, a generic_subprogram_declaration, or a generic_instantiation, of the same declarative_part or program unit declaration.
AARM Ramification: If you want to denote a subprogram_body that is not a completion, or a package_declaration, for example, you have to put the pragma inside.
Certain program unit pragmas are defined to be /library unit pragmas/. If a library unit pragma applies to a program unit, the program unit shall be a library unit.
AARM Ramification: This, together with the rules for program unit pragmas above, implies that if a library unit pragma applies to a subprogram_declaration (and similar things), it has to appear immediately after the compilation_unit, whereas if the pragma applies to a package_declaration, a subprogram_body that is not a completion (and similar things), it has to appear inside, as the first declarative_item.
Static Semantics
A library unit pragma that applies to a generic unit does not apply to its instances, unless a specific rule for the pragma specifies the contrary.
Implementation Advice
When applied to a generic unit, a program unit pragma that is not a library unit pragma should apply to each instance of the generic unit for which there is not an overriding pragma applied directly to the instance.
Replace the clause added by AI12-0409-1 with (this includes the text of the replaced clause):
J.15.14 Elaboration Control Pragmas
This subclause defines pragmas that specify aspects that help control the elaboration order of library_items.
AARM Discussion: Pragmas that do not have associated aspects still appear in 10.2.1. The pragmas presented below are shown in the order that the aspects are defined in 10.2.1.
Syntax
The following pragmas are defined with the given forms:
pragma Preelaborate[(/library_unit_/name)];
pragma Preelaborable_Initialization(direct_name);
pragma Pure[(/library_unit_/name)];
pragma Elaborate_Body[(/library_unit_/name)];
Pragmas Preelaborate, Pure, and Elaborate_Body are library unit pragmas.
Static Semantics
A pragma Preelaborate specifies that a library unit is preelaborated, namely that the Preelaborate aspect (see 10.2.1) of the library unit is True.
A pragma Pure specifies that a library unit is declared pure, namely that the Pure aspect (see 10.2.1) of the library unit is True.
A pragma Elaborate_Body specifies that @Redundant[a library unit requires a completion, namely that] the Elaborate_Body aspect (see 10.2.1) of the library unit is True.
Legality Rules
A pragma Preelaborable_Initialization specifies that the Preelaborable_Initialization aspect (see 10.2.1) for a composite type is True. This pragma shall appear in the visible part of a package or generic package.
If the pragma appears in the first declaration list of a package_specification, then the direct_name shall denote the first subtype of a composite type, and the type shall be declared immediately within the same package as the pragma. The composite type shall be one for which the Preelaborable_Initialization aspect can be directly specified as True. In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance of a generic unit.
If the pragma appears in a generic_formal_part, then the direct_name shall denote a type declared in the same generic_formal_part as the pragma, and be one for which the Preelaborable_Initialization aspect can be directly specified as True.
Note: Pragmas Elaborate and Elaborate_All, which do not have associated aspects, are found in 10.2.1.
J.15.15 Distribution Pragmas
This subclause defines pragmas that specify properties of units for distributed systems.
Syntax
The following pragmas are defined with the given forms:
pragma Shared_Passive[(/library_unit_/name)];
pragma Remote_Types[(/library_unit_/name)];
pragma Remote_Call_Interface[(/library_unit_/name)];
pragma All_Calls_Remote[(/library_unit_/name)];
Each of these pragmas is a library unit pragma.
Static Semantics
A /categorization pragma/ is a pragma that specifies a corresponding categorization aspect.
The pragmas Shared_Passive, Remote_Types, and Remote_Call_Interface are categorization pragmas. In addition, the pragma Pure (see J.15.14) is considered a categorization pragma.
[Editor's note: I don't think the term "categorization pragma" is used anywhere now. We could drop it altogether; I didn't do that in case it matters to someone (for instance, in error messages).]
A pragma Shared_Passive specifies that a library unit is a shared passive library unit, namely that the Shared_Passive aspect (see E.2.1) of the library unit is True.
A pragma Remote_Types specifies that a library unit is a remote types library unit, namely that the Remote_Types aspect (see E.2.2) of the library unit is True.
A pragma Remote_Call_Interface specifies that a library unit is a remote call interface, namely that the Remote_Call_Interface aspect (see E.2.3) of the library unit is True.
A pragma All_Calls_Remote specifies that the All_Calls_Remote aspect (see E.2.3) of the library unit is True.
!discussion
Pragma Preelaborable_Initialization has already made the trip to Annex J. It makes sense for the related Preelaborate, Pure, and Elaborate_Body pragmas to follow.
The original comment also raised the point that there are no longer any language-defined program unit pragmas or library unit pragmas that are not obsolete. Therefore, we move the definition of those terms to J.15 as well.
This is really a presentation change. There is no (required) effect on implementations of this change. It is implementation-defined whether No_Obsolescent_Features applies to obsolescent pragmas, so an implementation does not even need to change the implementation of that restriction (it can if it wants, of course).
!corrigendum 7.2(4)
Replace the paragraph:
A package_body shall be the completion of a previous package_declaration or generic_package_declaration. A library package_declaration or library generic_package_declaration shall not have a body unless it requires a body; pragma Elaborate_Body can be used to require a library_unit_declaration to have a body (see 10.2.1) if it would not otherwise require one.
by:
A package_body shall be the completion of a previous package_declaration or generic_package_declaration. A library package_declaration or library generic_package_declaration shall not have a body unless it requires a body; the Elaborate_Body aspect can be used to require a library_unit_declaration to have a body (see 10.2.1) if it would not otherwise require one.
!corrigendum 10.1.5(1)
Replace the paragraph:
This subclause discusses pragmas related to program units, library units, and compilations.
by:
This subclause discusses pragmas related to compilations.
!corrigendum 10.1.5(2)
Delete the paragraph:
Certain pragmas are defined to be program unit pragmas. A name given as the argument of a program unit pragma shall resolve to denote the declarations or renamings of one or more program units that occur immediately within the declarative region or compilation in which the pragma immediately occurs, or it shall resolve to denote the declaration of the immediately enclosing program unit (if any); the pragma applies to the denoted program unit(s). If there are no names given as arguments, the pragma applies to the immediately enclosing program unit.
!corrigendum 10.1.5(3)
Delete the paragraph:
A program unit pragma shall appear in one of these places:
!corrigendum 10.1.5(4)
Delete the paragraph:
!corrigendum 10.1.5(5/1)
Delete the paragraph:
!corrigendum 10.1.5(6)
Delete the paragraph:
!corrigendum 10.1.5(7/3)
Delete the paragraph:
Certain program unit pragmas are defined to be library unit pragmas. If a library unit pragma applies to a program unit, the program unit shall be a library unit.
!corrigendum 10.1.5(7.1/1)
Delete the paragraph:
A library unit pragma that applies to a generic unit does not apply to its instances, unless a specific rule for the pragma specifies the contrary.
!corrigendum 10.1.5(10/1)
Delete the paragraph:
When applied to a generic unit, a program unit pragma that is not a library unit pragma should apply to each instance of the generic unit for which there is not an overriding pragma applied directly to the instance.
!corrigendum 10.2(15/3)
Replace the paragraph:
by:
!corrigendum 10.2(33)
Replace the paragraph:
10 An order of elaboration of library_items that is consistent with the partial ordering defined above does not always ensure that each library_unit_body is elaborated before any other compilation unit whose elaboration necessitates that the library_unit_body be already elaborated. (In particular, there is no requirement that the body of a library unit be elaborated as soon as possible after the library_unit_declaration is elaborated, unless the pragmas in subclause 10.2.1 are used.)
by:
10 An order of elaboration of library_items that is consistent with the partial ordering defined above does not always ensure that each library_unit_body is elaborated before any other compilation unit whose elaboration necessitates that the library_unit_body be already elaborated. (In particular, there is no requirement that the body of a library unit be elaborated as soon as possible after the library_unit_declaration is elaborated, unless the pragmas or aspects in subclause 10.2.1 are used.)
!corrigendum 10.2.1(1)
Replace the paragraph:
This subclause defines pragmas that help control the elaboration order of library_items.
by:
This subclause defines aspects and pragmas that help control the elaboration order of library_items.
!corrigendum 10.2.1(2)
Delete the paragraph:
The form of a pragma Preelaborate is as follows:
!corrigendum 10.2.1(3)
Delete the paragraph:
  pragma Preelaborate (library_unit_name);
!corrigendum 10.2.1(4)
Delete the paragraph:
A pragma Preelaborate is a library unit pragma.
!corrigendum 10.2.1(10.1/3)
Replace the paragraph:
by:
!corrigendum 10.2.1(11/3)
Replace the paragraph:
A pragma Preelaborate (or pragma Pure — see below) is used to specify that a library unit is preelaborated, namely that the Preelaborate aspect of the library unit is True; all compilation units of the library unit are preelaborated. The declaration and body of a preelaborated library unit, and all subunits that are elaborated as part of elaborating the library unit, shall be preelaborable. All compilation units of a preelaborated library unit shall depend semantically only on declared pure or preelaborated library_items. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. If a library unit is preelaborated, then its declaration, if any, and body, if any, are elaborated prior to all nonpreelaborated library_items of the partition.
by:
When the library unit aspect (see 13.1.1) Preelaborate of a program unit is True, the unit is said to be preelaborated. When the Preelaborate aspect is specified True for a library unit, all compilation units of the library unit are preelaborated. The declaration and body of a preelaborated library unit, and all subunits that are elaborated as part of elaborating the library unit, shall be preelaborable. All compilation units of a preelaborated library unit shall depend semantically only on declared pure or preelaborated library_items. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. If a library unit is preelaborated, then its declaration, if any, and body, if any, are elaborated prior to all nonpreelaborated library_items of the partition.
!corrigendum 10.2.1(13)
Delete the paragraph:
The form of a pragma Pure is as follows:
!corrigendum 10.2.1(14)
Delete the paragraph:
  pragma Pure (library_unit_name);
!corrigendum 10.2.1(15)
Delete the paragraph:
A pragma Pure is a library unit pragma.
!corrigendum 10.2.1(17/3)
Replace the paragraph:
A pragma Pure is used to specify that a library unit is declared pure, namely that the Pure aspect of the library unit is True; all compilation units of the library unit are declared pure. In addition, the limited view of any library package is declared pure. The declaration and body of a declared pure library unit, and all subunits that are elaborated as part of elaborating the library unit, shall be pure. All compilation units of a declared pure library unit shall depend semantically only on declared pure library_items. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. Furthermore, the full view of any partial view declared in the visible part of a declared pure library unit that has any available stream attributes shall support external streaming (see 13.13.2).
by:
When the library unit aspect Pure of a program unit is True, the unit is said to be declared pure. When the Pure aspect is specified True for a library unit, all compilation units of the library unit are declared pure. In addition, the limited view of any library package is declared pure. The declaration and body of a declared pure library unit, and all subunits that are elaborated as part of elaborating the library unit, shall be pure. All compilation units of a declared pure library unit shall depend semantically only on declared pure library_items. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. Furthermore, the full view of any partial view declared in the visible part of a declared pure library unit that has any available stream attributes shall support external streaming (see 13.13.2).
!corrigendum 10.2.1(19)
Replace the paragraph:
The form of a pragma Elaborate, Elaborate_All, or Elaborate_Body is as follows:
by:
The following pragmas are defined with the given forms:
!corrigendum 10.2.1(22)
Delete the paragraph:
  pragma Elaborate_Body (library_unit_name);
!corrigendum 10.2.1(24)
Delete the paragraph:
A pragma Elaborate_Body is a library unit pragma.
!corrigendum 10.2.1(25/3)
Replace the paragraph:
If the aspect Elaborate_Body is True for a declaration (including when pragma Elaborate_Body applies), then the declaration requires a completion (a body).
by:
If the aspect Elaborate_Body is True for a declaration, then the declaration requires a completion (a body).
!corrigendum 10.2.1(26.1/3)
Replace the paragraph:
A pragma Elaborate_Body sets the Elaborate_Body representation aspect of the library unit to which it applies to the value True. If the Elaborate_Body aspect of a library unit is True, the body of the library unit is elaborated immediately after its declaration.
by:
If the Elaborate_Body aspect of a library unit is True, the body of the library unit is elaborated immediately after its declaration.
!corrigendum 13.1(9.3/5)
Replace the paragraph:
If a representation item, operational item, or aspect_specification is given that directly specifies an aspect of an entity, then it is illegal to give another representation item, operational item, or aspect_specification that directly specifies the same aspect of the entity.
by:
If a representation item, operational item, library unit pragma (see J.15), or aspect_specification is given that directly specifies an aspect of an entity, then it is illegal to give another representation item, operational item, library unit pragma, or aspect_specification that directly specifies the same aspect of the entity.
!corrigendum 13.1.1(32/4)
Replace the paragraph:
Any aspect specified by a representation pragma or library unit pragma that has a local_name as its single argument may be specified by an aspect_specification, with the entity being the local_name. The aspect_definition is expected to be of type Boolean. The expression shall be static. Notwithstanding what this International Standard says elsewhere, the expression of an aspect that can be specified by a library unit pragma is resolved and evaluated at the point where it occurs in the aspect_specification, rather than the first freezing point of the associated package.
by:
Some aspects are defined to be library unit aspects. Library unit aspects are of type Boolean. The expression specifying a library unit aspect shall be static. Library unit aspects are defined for all program units, but shall be specified only for library units. Notwithstanding what this International Standard says elsewhere, the expression of a library unit aspect is resolved and evaluated at the point where it occurs in the aspect_specification, rather than the first freezing point of the associated unit.
!corrigendum C.4(1/3)
Replace the paragraph:
This subclause specifies additional implementation and documentation requirements for the Preelaborate pragma (see 10.2.1).
by:
This subclause specifies additional implementation and documentation requirements for the Preelaborate aspect (see 10.2.1).
!corrigendum E.1(15)
Replace the paragraph:
NOTES
4 Library units are grouped into partitions after compile time, but before run time. At compile time, only the relevant library unit properties are identified using categorization pragmas.
by:
NOTES
4 Library units are grouped into partitions after compile time, but before run time. At compile time, only the relevant library unit properties are identified using categorization aspects.
!corrigendum E.2(2/3)
Replace the paragraph:
A categorization pragma is a library unit pragma (see 10.1.5) that specifies a corresponding categorization aspect. A categorization aspect restricts the declarations, child units, or semantic dependences of the library unit to which it applies. A categorized library unit is a library unit that has a categorization aspect that is True.
by:
A categorization aspect restricts the declarations, child units, or semantic dependences of the library unit to which it applies. A categorized library unit is a library unit that has a categorization aspect that is True.
!corrigendum E.2(3/3)
Replace the paragraph:
The pragmas Shared_Passive, Remote_Types, and Remote_Call_Interface are categorization pragmas, and the associated aspects are categorization aspects. In addition, for the purposes of this Annex, the aspect Pure (see 10.2.1) is considered a categorization aspect and the pragma Pure is considered a categorization pragma.
by:
The aspects Shared_Passive, Remote_Types, and Remote_Call_Interface are categorization aspects. In addition, for the purposes of this Annex, the aspect Pure (see 10.2.1) is considered a categorization aspect.
!corrigendum E.2(14)
Delete the paragraph:
Implementations are allowed to define other categorization pragmas.
!corrigendum E.2.1(2)
Delete the paragraph:
The form of a pragma Shared_Passive is as follows:
!corrigendum E.2.1(3)
Delete the paragraph:
  pragma Shared_Passive (library_unit_name);
!corrigendum E.2.1(4/3)
Replace the paragraph:
A pragma Shared_Passive is used to specify that a library unit is a shared passive library unit, namely that the Shared_Passive aspect of the library unit is True. The following restrictions apply to such a library unit:
by:
When the library unit aspect (see 13.1.1) Shared_Passive of a library unit is True, the library unit is a shared passive library unit. The following restrictions apply to such a library unit:
!corrigendum E.2.2(2)
Delete the paragraph:
The form of a pragma Remote_Types is as follows:
!corrigendum E.2.2(3)
Delete the paragraph:
  pragma Remote_Types (library_unit_name);
!corrigendum E.2.2(4/3)
Replace the paragraph:
A pragma Remote_Types is used to specify that a library unit is a remote types library unit, namely that the Remote_Types aspect of the library unit is True. The following restrictions apply to such a library unit:
by:
When the library unit aspect (see 13.1.1) Remote_Types of a library unit is True, the library unit is a remote types library unit. The following restrictions apply to such a library unit:
!corrigendum E.2.3(2)
Delete the paragraph:
The form of a pragma Remote_Call_Interface is as follows:
!corrigendum E.2.3(3)
Delete the paragraph:
  pragma Remote_Call_Interface (library_unit_name);
!corrigendum E.2.3(4)
Delete the paragraph:
The form of a pragma All_Calls_Remote is as follows:
!corrigendum E.2.3(5)
Delete the paragraph:
  pragma All_Calls_Remote (library_unit_name);
!corrigendum E.2.3(6)
Delete the paragraph:
A pragma All_Calls_Remote is a library unit pragma.
!corrigendum E.2.3(7/3)
Replace the paragraph:
A pragma Remote_Call_Interface is used to specify that a library unit is a remote call interface (RCI), namely that the Remote_Call_Interface aspect of the library unit is True. A subprogram declared in the visible part of such a library unit, or declared by such a library unit, is called a remote subprogram.
by:
When the library unit aspect (see 13.1.1) Remote_Call_Interface of a library unit is True, the library unit is a remote call interface (RCI). A subprogram declared in the visible part of such a library unit, or declared by such a library unit, is called a remote subprogram.
!corrigendum E.2.3(16/3)
Replace the paragraph:
A pragma All_Calls_Remote sets the All_Calls_Remote representation aspect of the library unit to which the pragma applies to the value True. If the All_Calls_Remote aspect of a library unit is True, the library unit shall be a remote call interface.
by:
All_Calls_Remote is a library unit aspect. If the All_Calls_Remote aspect of a library unit is True, the library unit shall be a remote call interface.
!corrigendum E.2.3(20/3)
Replace the paragraph:
An implementation need not support the Remote_Call_Interface pragma or aspect nor the All_Calls_Remote pragma. Explicit message-based communication between active partitions can be supported as an alternative to RPC.
by:
An implementation need not support the Remote_Call_Interface aspect nor the All_Calls_Remote aspect. Explicit message-based communication between active partitions can be supported as an alternative to RPC.
!corrigendum J.15(1/3)
Insert after the paragraph:
Pragmas can be used as an alternative to aspect_specifications to specify certain aspects.
the new paragraphs:
Name Resolution Rules
Certain pragmas are defined to be program unit pragmas. A name given as the argument of a program unit pragma shall resolve to denote the declarations or renamings of one or more program units that occur immediately within the declarative region or compilation in which the pragma immediately occurs, or it shall resolve to denote the declaration of the immediately enclosing program unit (if any); the pragma applies to the denoted program unit(s). If there are no names given as arguments, the pragma applies to the immediately enclosing program unit.
Legality Rules
A program unit pragma shall appear in one of these places:
Certain program unit pragmas are defined to be library unit pragmas. If a library unit pragma applies to a program unit, the program unit shall be a library unit.
Static Semantics
A library unit pragma that applies to a generic unit does not apply to its instances, unless a specific rule for the pragma specifies the contrary.
Implementation Advice
When applied to a generic unit, a program unit pragma that is not a library unit pragma should apply to each instance of the generic unit for which there is not an overriding pragma applied directly to the instance.
!corrigendum J.15.14(0)
Insert new clause:
This subclause defines pragmas that set aspects that help control the elaboration order of library_items.
** Find the rest in the conflict file **
!corrigendum J.15.15(0)
Insert new clause:
This subclause defines pragmas that specify properties of units for distributed systems.
Syntax
The following pragmas are defined with the given forms:
  pragma Shared_Passive (library_unit_name);
  pragma Remote_Types (library_unit_name);
  pragma Remote_Call_Interface (library_unit_name);
  pragma All_Calls_Remote (library_unit_name);
Each of these pragmas is a library unit pragma.
Static Semantics
A categorization pragma is a pragma that specifies a corresponding categorization aspect.
The pragmas Shared_Passive, Remote_Types, and Remote_Call_Interface are categorization pragmas. In addition, the pragma Pure (see J.15.14) is considered a categorization pragma.
A pragma Shared_Passive specifies that a library unit is a shared passive library unit, namely that the Shared_Passive aspect (see E.2.1) of the library unit is True.
A pragma Remote_Types specifies that a library unit is a remote types library unit, namely that the Remote_Types aspect (see E.2.2) of the library unit is True.
A pragma Remote_Call_Interface specifies that a library unit is a remote call interface, namely that the Remote_Call_Interface aspect (see E.2.3) of the library unit is True.
A pragma All_Calls_Remote specifies that the All_Calls_Remote aspect (see E.2.3) of the library unit is True.
!ASIS
No ASIS effect.
!ACATS test
No ACATS tests are needed. (It is implementation-defined whether No_Obsolescent_Features applies to obsolescent pragmas, and thus it is not usefully testable.)
!appendix

From the AARM Review of John Barnes.

10.2.1  Elaboration Control

I thought that the description was going to be changed so that aspects such as 
Pure would usually be set by an aspect rather than a pragma. It seems topsy 
turvy therefore to introduce pragmas such as Pure here still. Should we not 
be introducing the concepts here and the use of aspects and then the pragmas 
themselves should be in an annex? A lot of predefined units now show 
preelaborate in a list of aspects (when adding nonblocking I think). Eg 
Ada.Tags.

It seems quite hard to deduce that indeed a unit can be declared Pure by 
writing

package Pig
       with Pure is

I believe that it was thought that I was against using Pure as in

package Ada 
     with Pure is
end Ada;

What I disliked is the juxataposition is end. It occurs in 
System.Atomic_Operations in C.6.1. Never mind.

It also occurs with generic signatures. I grumble about it on page 496 of 
my book.

I don't think it could happen in Ada 83. It might have happened with tasks 
that had no entries, but the abbreviation

task T;

rather than

task T is
end T;

was introduced. And of course Ada 83 did not have children so a Package 
without any subprograms was a bit pointless.

Anyway, enough of this ranting, I will turn to Exceptions.

---

Earlier:

10.1.5               I am surprised that there are no changes in the 
discussion on pragmas. It is probably OK since this discusses only 
certain pragmas and not pragmas as a whole. Maybe there should be a 
cross reference to the use of pragmas for setting aspects.

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


Questions? Ask the ACAA Technical Agent