CVS difference for ai12s/ai12-0417-1.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0417-1.txt

--- ai12s/ai12-0417-1.txt	2021/01/23 05:57:34	1.4
+++ ai12s/ai12-0417-1.txt	2021/02/26 23:52:23	1.5
@@ -1,6 +1,53 @@
-!standard 10.2.1(2)                                   20-12-08  AI12-0417-1/01
+!standard 7.2(4)                                       21-02-25  AI12-0417-1/02
+!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(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
@@ -30,30 +77,1013 @@
 
 !wording
 
-** TBD **
+Modify 7.2(4):
 
-[Editor's note: I didn't work out the detailed wording changes, as they
-should be fairly obvious, and I didn't want to spend the time until we've
-discussed whether to do this at all.
-
-Note that we need to change both 10.2.1 and E.2 if we do this, as well as
-create one or more new J.15 subclauses.
-
-John also raised the interesting question of whether we still need the
-definitions of "program unit pragmas" and "library unit pragmas" in 10.1.5,
-or whether that too should move to Annex J. I haven't checked if any of
-these still remain in the core or annexes.]
+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.
+
+Modify 10.2.1(19):
+The form of a pragma Elaborate[,]{ or} Elaborate_All[, or Elaborate_Body] is
+as follows: 
+
+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(27.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 [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/. For a library unit
+aspect, the}[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.
+{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 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 set 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. These pragmas are presented in the order that the aspects are
+defined in 10.2.1.
+
+     Syntax
+ 
+  The form of pragmas Preelaborate, Preelaborable_Initialization, Pure, and
+  Elaborate_Body is as follows: 
+
+    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, by 
+setting the Preelaborate aspect (see 10.2.1) of the library unit to True.
+
+A pragma Pure specifies that a library unit is declared pure, by 
+setting the Pure aspect (see 10.2.1) of the library unit to True.
+
+A pragma Elaborate_Body @Redundant[specifies that a library unit 
+requires a completion,] by setting the Elaborate_Body aspect (see 10.2.1)
+of the library unit to 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 set properties of units for distributed
+systems.
+
+Syntax
+
+  The form of pragmas Shared_Passive, Remote_Types, Remote_Call_Interface, and
+  All_Calls_Remote is as follows: 
+
+     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, by setting the Shared_Passive aspect (see E.2.1) of the library
+unit to True.
+
+
+
 !discussion
 
 Pragma Preelaborable_Initialization has already made the trip to Annex J.
-It makes sense for the related Preelaboration and Pure pragmas to follow.
+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)
+
+@drepl
+A @fa<package_body> shall be the completion of a previous 
+@fa<package_declaration> or @fa<generic_package_declaration>. A library 
+@fa<package_declaration> or library @fa<generic_package_declaration> shall not 
+have a body unless it requires a body; @b<pragma> Elaborate_Body can be used
+to require a @fa<library_unit_declaration> to have a body (see 10.2.1) if it
+would not otherwise require one. 
+@dby
+A @fa<package_body> shall be the completion of a previous 
+@fa<package_declaration> or @fa<generic_package_declaration>. A library 
+@fa<package_declaration> or library @fa<generic_package_declaration> shall not 
+have a body unless it requires a body; the Elaborate_Body aspect can be used
+to require a @fa<library_unit_declaration> to have a body (see 10.2.1) if it
+would not otherwise require one. 
+
+!corrigendum 10.1.5(1)
+
+@drepl
+This subclause discusses pragmas related to program units, library units, 
+and @fa<compilation>s.
+@dby
+This subclause discusses pragmas related to @fa<compilation>s.
+
+!corrigendum 10.1.5(2)
+
+@ddel
+Certain @fa<pragma>s are defined to be @i<program unit pragmas>. A @fa<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 @fa<compilation> in which the @fa<pragma> 
+immediately occurs, or it shall resolve to denote the declaration of the 
+immediately enclosing program unit (if any); the @fa<pragma> applies to the 
+denoted program unit(s). If there are no @fa<name>s given as arguments, the 
+@fa<pragma> applies to the immediately enclosing program unit. 
+
+!corrigendum 10.1.5(3)
+
+@ddel
+A program unit pragma shall appear in one of these places: 
+
+!corrigendum 10.1.5(4)
+
+@ddel
+@xbullet<At the place of a @fa<compilation_unit>, in which case the @fa<pragma>
+shall immediately follow in the same @fa<compilation> (except for other 
+@fa<pragma>s) a @fa<library_unit_declaration> that is a
+@fa<subprogram_declaration>, @fa<generic_subprogram_declaration>, or 
+@fa<generic_instantiation>, and the @fa<pragma> shall have an argument that is
+a @fa<name> denoting that declaration.>
+
+!corrigendum 10.1.5(5/1)
+
+@ddel
+@xbullet<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 @fa<direct_name> that denotes the immediately
+enclosing program unit declaration.> 
+
+!corrigendum 10.1.5(6)
+
+@ddel
+@xbullet<At the place of a declaration other than the first, of a 
+@fa<declarative_part> or program unit declaration, in which case the
+@fa<pragma> shall have an argument, which shall be a @fa<direct_name> that
+denotes one or more of the following (and nothing else): a 
+@fa<subprogram_declaration>, a @fa<generic_subprogram_declaration>, or a 
+@fa<generic_instantiation>, of the same @fa<declarative_part> or program unit
+declaration.>
+
+!corrigendum 10.1.5(7/3)
+
+@ddel
+Certain program unit pragmas are defined to be @i<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)
+
+@ddel
+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)
+
+@ddel
+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)
+
+@drepl
+@xbullet<Any included @fa<library_unit_declaration> for which aspect Elaborate_Body
+is True (including when a @fa<pragma> Elaborate_Body applies) is immediately 
+followed by its @fa<library_unit_body>, if included.>
+@dby
+@xbullet<Any included @fa<library_unit_declaration> for which aspect Elaborate_Body
+is True is immediately followed by its @fa<library_unit_body>, if included.>
+
+!corrigendum 10.2(33)
+
+@drepl
+@xindent<@s9<10  An order of elaboration of @fa<library_item>s that is consistent with
+the partial ordering defined above does not always ensure that each
+@fa<library_unit_body> is elaborated before any other compilation unit
+whose elaboration necessitates that the @fa<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
+@fa<library_unit_declaration> is elaborated, unless the pragmas in
+subclause 10.2.1 are used.)>>
+@dby
+@xindent<@s9<10  An order of elaboration of @fa<library_item>s that is consistent with
+the partial ordering defined above does not always ensure that each
+@fa<library_unit_body> is elaborated before any other compilation unit
+whose elaboration necessitates that the @fa<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
+@fa<library_unit_declaration> is elaborated, unless the pragmas or aspects in
+subclause 10.2.1 are used.)>>
+
+
+!corrigendum 10.2.1(1)
+
+@drepl
+This subclause defines pragmas that help control the elaboration order of 
+@fa<library_item>s.
+@dby
+This subclause defines aspects and pragmas that help control the elaboration
+order of @fa<library_item>s.
+
+!corrigendum 10.2.1(2)
+
+@ddel
+The form of a @fa<pragma> Preelaborate is as follows: 
+
+!corrigendum 10.2.1(3)
+
+@ddel
+@xindent<@ @ @b<pragma> Preelaborate (@i<library_unit_>@fa<name>);>
+
+!corrigendum 10.2.1(4)
+
+@ddel
+@xindent<A @fa<pragma> Preelaborate is a library unit pragma.>
+
+!corrigendum 10.2.1(10.1/3)
+
+@drepl
+@xbullet<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 
+@fa<pragma> Preelaborable_Initialization has 
+been applied to the formal type;>
+@dby
+@xbullet<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 Preelaborable_Initialization aspect was specified for the formal type;>
+
+!corrigendum 10.2.1(11/3)
+
+@drepl
+A @fa<pragma> Preelaborate (or @fa<pragma> Pure @emdash see below) is used to specify that
+a library unit is @i<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 @fa<library_item>s. 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 @fa<library_item>s of the
+partition.
+@dby
+When the library unit aspect (see 13.1.1) Preelaborate of a program unit is
+True, the unit is said to be @i<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 @fa<library_item>s. 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 @fa<library_item>s of the
+partition.
+
+!corrigendum 10.2.1(13)
+
+@ddel
+The form of a @fa<pragma> Pure is as follows: 
+
+!corrigendum 10.2.1(14)
+
+@ddel
+@xindent<@ @ @b<pragma> Pure (@i<library_unit_>@fa<name>);>
+
+!corrigendum 10.2.1(15)
+
+@ddel
+@xindent<A @fa<pragma> Pure is a library unit pragma.>
+
+!corrigendum 10.2.1(17/3)
+
+@drepl
+A @fa<pragma> Pure is used to specify that a library unit is @i<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 @fa<library_item>s.
+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).
+@dby
+When the library unit aspect Pure of a program unit is True, the unit is said
+to be @i<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 @fa<library_item>s.
+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)
+
+@drepl
+The form of a @fa<pragma> Elaborate, Elaborate_All, or Elaborate_Body is as 
+follows: 
+@dby
+The form of a @fa<pragma> Elaborate or Elaborate_All is as follows: 
+
+!corrigendum 10.2.1(22)
+
+@ddel
+@xindent<@ @ @b<pragma> Elaborate_Body (@i<library_unit_>@fa<name>);>
+
+!corrigendum 10.2.1(24)
+
+@ddel
+@xindent<A @fa<pragma> Elaborate_Body is a library unit pragma.>
+
+!corrigendum 10.2.1(25/3)
+
+@drepl
+If the aspect Elaborate_Body is True for a declaration (including when 
+@fa<pragma> Elaborate_Body applies), then the declaration requires a 
+completion (a body).
+@dby
+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)
+
+@drepl
+A @fa<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.
+@dby
+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)
+
+@drepl
+If a representation item, operational item, or @fa<aspect_specification> is given
+that directly specifies an aspect of an entity, then it is illegal to give
+another representation item, operational item, or @fa<aspect_specification> that
+directly specifies the same aspect of the entity.
+@dby
+If a representation item, operational item, library unit pragma (see J.15),
+or @fa<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 @fa<aspect_specification> that directly specifies
+the same aspect of the entity.
+
+!corrigendum 13.1.1(32/4)
+
+@drepl
+Any aspect specified by a representation pragma or library unit pragma that has
+a @fa<local_name> as its single argument may be specified by an
+@fa<aspect_specification>, with the entity being the @fa<local_name>. The
+@fa<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
+@fa<aspect_specification>, rather than the first freezing point of the
+associated package.
+@dby
+Some aspects are defined to be @i<library unit aspects>. For a library unit
+aspect, the @fa<aspect_definition> is expected to be of type Boolean. The 
+expression 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
+@fa<aspect_specification>, rather than the first freezing point of the
+associated unit.
+
+
+!corrigendum C.4(1/3)
+
+@drepl
+This subclause specifies additional implementation and documentation 
+requirements for the Preelaborate pragma (see 10.2.1).
+@dby
+This subclause specifies additional implementation and documentation 
+requirements for the Preelaborate aspect (see 10.2.1).
+
+!corrigendum E.1(15)
+
+@drepl
+@xindent<@s9<NOTES@hr
+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.>>
+@dby
+@xindent<@s9<NOTES@hr
+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)
+
+@drepl
+A @i<categorization pragma> is a library unit pragma (see 10.1.5) that 
+specifies a corresponding @i<categorization aspect>. A categorization 
+aspect restricts the declarations, child units, or semantic dependences 
+of the library unit to which it applies. A @i<categorized library unit> is 
+a library unit that has a categorization aspect that is True.
+@dby
+A @i<categorization aspect> restricts the declarations, child units, 
+or semantic dependences of the library unit to which it applies. A 
+@i<categorized library unit> is a library unit that has a categorization aspect
+that is True.
+
+!corrigendum E.2(3/3)
+
+@drepl
+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.
+@dby
+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)
+
+@ddel
+Implementations are allowed to define other categorization pragmas.
+
+!corrigendum E.2.1(2)
+
+@ddel
+The form of a @fa<pragma> Shared_Passive is as follows: 
+
+!corrigendum E.2.1(3)
+
+@ddel
+@xindent<@ @ @b<pragma> Shared_Passive (@i<library_unit_>@fa<name>);>
+
+!corrigendum E.2.1(4/3)
+
+@drepl
+A @fa<pragma> Shared_Passive is used to specify that a library unit is a @i<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:
+@dby
+When the library unit aspect (see 13.1.1) Shared_Passive of a library unit is 
+True, the library unit is a @i<shared passive library unit>. The following 
+restrictions apply to such a library unit:
+
+!corrigendum E.2.2(2)
+
+@ddel
+The form of a @fa<pragma> Remote_Types is as follows: 
+
+!corrigendum E.2.2(3)
+
+@ddel
+@xindent<@ @ @b<pragma> Remote_Types (@i<library_unit_>@fa<name>);>
+
+!corrigendum E.2.2(4/3)
+
+@drepl
+A @fa<pragma> Remote_Types is used to specify that a library unit is a @i<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:
+@dby
+When the library unit aspect (see 13.1.1) Remote_Types of a library unit is 
+True, the library unit is a @i<remote types library unit>. The following 
+restrictions apply to such a library unit:
+
+!corrigendum E.2.3(2)
+
+@ddel
+The form of a @fa<pragma> Remote_Call_Interface is as follows: 
+
+!corrigendum E.2.3(3)
+
+@ddel
+@xindent<@ @ @b<pragma> Remote_Call_Interface (@i<library_unit_>@fa<name>);>
+
+!corrigendum E.2.3(4)
+
+@ddel
+The form of a @fa<pragma> All_Calls_Remote is as follows: 
+
+!corrigendum E.2.3(5)
+
+@ddel
+@xindent<@ @ @b<pragma> All_Calls_Remote (@i<library_unit_>@fa<name>);>
+
+!corrigendum E.2.3(6)
+
+@ddel
+A @fa<pragma> All_Calls_Remote is a library unit pragma. 
+
+!corrigendum E.2.3(7/3)
+
+@drepl
+A @fa<pragma> Remote_Call_Interface is used to specify that a library unit
+is a @i<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 @i<remote subprogram>.
+@dby
+When the library unit aspect (see 13.1.1) Remote_Call_Interface of a library
+unit is True, the library unit is a @i<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 @i<remote subprogram>.
+
+!corrigendum E.2.3(16/3)
+
+@drepl
+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.
+@dby
+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)
+
+@drepl
+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. 
+@dby
+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)
+
+@dinsa
+Pragmas can be used as an alternative to aspect_specifications to specify 
+certain aspects.
+@dinss
+@s8<@i<Name Resolution Rules>>
+
+Certain @fa<pragma>s are defined to be @i<program unit pragmas>. A @fa<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 @fa<compilation> in which the @fa<pragma> 
+immediately occurs, or it shall resolve to denote the declaration of the 
+immediately enclosing program unit (if any); the @fa<pragma> applies to the 
+denoted program unit(s). If there are no @fa<name>s given as arguments, the 
+@fa<pragma> applies to the immediately enclosing program unit. 
+
+@s8<@i<Legality Rules>>
+
+A program unit pragma shall appear in one of these places: 
+
+@xbullet<At the place of a @fa<compilation_unit>, in which case the @fa<pragma>
+shall immediately follow in the same @fa<compilation> (except for other 
+@fa<pragma>s) a @fa<library_unit_declaration> that is a
+@fa<subprogram_declaration>, @fa<generic_subprogram_declaration>, or 
+@fa<generic_instantiation>, and the @fa<pragma> shall have an argument that is
+a @fa<name> denoting that declaration.>
+
+@xbullet<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 @fa<direct_name> that denotes the immediately
+enclosing program unit declaration.> 
+
+@xbullet<At the place of a declaration other than the first, of a 
+@fa<declarative_part> or program unit declaration, in which case the
+@fa<pragma> shall have an argument, which shall be a @fa<direct_name> that
+denotes one or more of the following (and nothing else): a 
+@fa<subprogram_declaration>, a @fa<generic_subprogram_declaration>, or a 
+@fa<generic_instantiation>, of the same @fa<declarative_part> or program unit
+declaration.>
+
+Certain program unit pragmas are defined to be @i<library unit pragmas>. If a 
+library unit pragma applies to a program unit, the program unit shall be a
+library unit. 
+
+@s8<@i<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. 
+
+@s8<@i<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)
+
+@dinsc
+This subclause defines pragmas that set aspects that help control the 
+elaboration order of @fa<library_item>s. 
+
+** Find the rest in the conflict file **
+
+
+!corrigendum J.15.15(0)
+
+@dinsc
+This subclause defines pragmas that set properties of units for distributed
+systems.
+
+@s8<@i<Syntax>>
+
+The form of @fa<pragma>s Shared_Passive, Remote_Types, Remote_Call_Interface,
+and All_Calls_Remote is as follows: 
+
+@xindent<@ @ @b<pragma> Shared_Passive (@i<library_unit_>@fa<name>);>
+
+@xindent<@ @ @b<pragma> Remote_Types (@i<library_unit_>@fa<name>);>
+
+@xindent<@ @ @b<pragma> Remote_Call_Interface (@i<library_unit_>@fa<name>);>
+
+@xindent<@ @ @b<pragma> All_Calls_Remote (@i<library_unit_>@fa<name>);>
+
+Each of these pragmas is a library unit pragma.
+
+@s8<@i<Static Semantics>>
+
+A @i<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, by setting the Shared_Passive aspect (see E.2.1) of the library
+unit to True.
+
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent