!standard 2.8(29/3) 21-03-08 AI12-0417-1/04 !standard 7.2(4) !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 WG9 Approved 22-06-22 !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 Replace 2.8(29/3) with: pragma List(Off); -- turn off listing generation pragma Optimize(Off); -- turn off optional optimizations pragma Assertion_Policy(Check); -- check assertions pragma Assert(Exists(File_Name), Message => "Nonexistent file"); -- assert file exists [Editor's note: Remove obsolescent pragma from example.] 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 2.8(29/3) @drepl @xcode<@b List(Off); -- @ft<@i> @b Optimize(Off); -- @ft<@i> @b Pure(Rational_Numbers); -- @ft<@i> @b Assert(Exists(File_Name), Message =@> "Nonexistent file"); -- @ft<@i>> @dby @xcode<@b List(Off); -- @ft<@i> @b Optimize(Off); -- @ft<@i> @b Assertion_Policy(Check); -- @ft<@i> @b Assert(Exists(File_Name), Message =@> "Nonexistent file"); -- @ft<@i>> !corrigendum 7.2(4) @drepl A @fa shall be the completion of a previous @fa or @fa. A library @fa or library @fa shall not have a body unless it requires a body; @b Elaborate_Body can be used to require a @fa to have a body (see 10.2.1) if it would not otherwise require one. @dby A @fa shall be the completion of a previous @fa or @fa. A library @fa or library @fa shall not have a body unless it requires a body; the Elaborate_Body aspect can be used to require a @fa 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 @fas. @dby This subclause discusses pragmas related to @fas. !corrigendum 10.1.5(2) @ddel Certain @fas are defined to be @i. A @fa 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 in which the @fa immediately occurs, or it shall resolve to denote the declaration of the immediately enclosing program unit (if any); the @fa applies to the denoted program unit(s). If there are no @fas given as arguments, the @fa 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, in which case the @fa shall immediately follow in the same @fa (except for other @fas) a @fa that is a @fa, @fa, or @fa, and the @fa shall have an argument that is a @fa denoting that declaration.> !corrigendum 10.1.5(5/1) @ddel @xbullet that denotes the immediately enclosing program unit declaration.> !corrigendum 10.1.5(6) @ddel @xbullet or program unit declaration, in which case the @fa shall have an argument, which shall be a @fa that denotes one or more of the following (and nothing else): a @fa, a @fa, or a @fa, of the same @fa or program unit declaration.> !corrigendum 10.1.5(7/3) @ddel Certain program unit pragmas are defined to be @i. 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 for which aspect Elaborate_Body is True (including when a @fa Elaborate_Body applies) is immediately followed by its @fa, if included.> @dby @xbullet for which aspect Elaborate_Body is True is immediately followed by its @fa, if included.> !corrigendum 10.2(33) @drepl @xindent<@s9<10 An order of elaboration of @fas that is consistent with the partial ordering defined above does not always ensure that each @fa is elaborated before any other compilation unit whose elaboration necessitates that the @fa 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 is elaborated, unless the pragmas in subclause 10.2.1 are used.)>> @dby @xindent<@s9<10 An order of elaboration of @fas that is consistent with the partial ordering defined above does not always ensure that each @fa is elaborated before any other compilation unit whose elaboration necessitates that the @fa 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 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 @fas. @dby This subclause defines aspects and pragmas that help control the elaboration order of @fas. !corrigendum 10.2.1(2) @ddel The form of a @fa Preelaborate is as follows: !corrigendum 10.2.1(3) @ddel @xindent<@ @ @b Preelaborate[(@i@fa)];> !corrigendum 10.2.1(4) @ddel @xindent Preelaborate is a library unit pragma.> !corrigendum 10.2.1(10.1/3) @drepl @xbullet Preelaborable_Initialization has been applied to the formal type;> @dby @xbullet !corrigendum 10.2.1(11/3) @drepl A @fa Preelaborate (or @fa Pure @emdash see below) is used to specify that a library unit is @i, 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 @fas. 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 @fas 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. 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 @fas. 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 @fas of the partition. !corrigendum 10.2.1(13) @ddel The form of a @fa Pure is as follows: !corrigendum 10.2.1(14) @ddel @xindent<@ @ @b Pure[(@i@fa)];> !corrigendum 10.2.1(15) @ddel @xindent Pure is a library unit pragma.> !corrigendum 10.2.1(17/3) @drepl A @fa Pure is used to specify that a library unit is @i, 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 @fas. 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. 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 @fas. 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 Elaborate, Elaborate_All, or Elaborate_Body is as follows: @dby The following @fas are defined with the given forms: !corrigendum 10.2.1(22) @ddel @xindent<@ @ @b Elaborate_Body[(@i@fa)];> !corrigendum 10.2.1(24) @ddel @xindent 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 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 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 is given that directly specifies an aspect of an entity, then it is illegal to give another representation item, operational item, or @fa that directly specifies the same aspect of the entity. @dby If a representation item, operational item, library unit pragma (see J.15), or @fa 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 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 as its single argument may be specified by an @fa, with the entity being the @fa. The @fa 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, rather than the first freezing point of the associated package. @dby Some aspects are defined to be @i. 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 document says elsewhere, the expression of a library unit aspect is resolved and evaluated at the point where it occurs in the @fa, 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> @dby @xindent<@s9> !corrigendum E.2(2/3) @drepl A @i is a library unit pragma (see 10.1.5) that specifies a corresponding @i. A categorization aspect restricts the declarations, child units, or semantic dependences of the library unit to which it applies. A @i is a library unit that has a categorization aspect that is True. @dby A @i restricts the declarations, child units, or semantic dependences of the library unit to which it applies. A @i 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 Shared_Passive is as follows: !corrigendum E.2.1(3) @ddel @xindent<@ @ @b Shared_Passive (@i@fa);> !corrigendum E.2.1(4/3) @drepl A @fa Shared_Passive is used to specify that a library unit is a @i, 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. The following restrictions apply to such a library unit: !corrigendum E.2.2(2) @ddel The form of a @fa Remote_Types is as follows: !corrigendum E.2.2(3) @ddel @xindent<@ @ @b Remote_Types[(@i@fa)];> !corrigendum E.2.2(4/3) @drepl A @fa Remote_Types is used to specify that a library unit is a @i, 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. The following restrictions apply to such a library unit: !corrigendum E.2.3(2) @ddel The form of a @fa Remote_Call_Interface is as follows: !corrigendum E.2.3(3) @ddel @xindent<@ @ @b Remote_Call_Interface[(@i@fa)];> !corrigendum E.2.3(4) @ddel The form of a @fa All_Calls_Remote is as follows: !corrigendum E.2.3(5) @ddel @xindent<@ @ @b All_Calls_Remote[(@i@fa)];> !corrigendum E.2.3(6) @ddel A @fa All_Calls_Remote is a library unit pragma. !corrigendum E.2.3(7/3) @drepl A @fa Remote_Call_Interface is used to specify that a library unit is a @i, 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. @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. A subprogram declared in the visible part of such a library unit, or declared by such a library unit, is called a @i. !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> Certain @fas are defined to be @i. A @fa 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 in which the @fa immediately occurs, or it shall resolve to denote the declaration of the immediately enclosing program unit (if any); the @fa applies to the denoted program unit(s). If there are no @fas given as arguments, the @fa applies to the immediately enclosing program unit. @s8<@i> A program unit pragma shall appear in one of these places: @xbullet, in which case the @fa shall immediately follow in the same @fa (except for other @fas) a @fa that is a @fa, @fa, or @fa, and the @fa shall have an argument that is a @fa denoting that declaration.> @xbullet that denotes the immediately enclosing program unit declaration.> @xbullet or program unit declaration, in which case the @fa shall have an argument, which shall be a @fa that denotes one or more of the following (and nothing else): a @fa, a @fa, or a @fa, of the same @fa or program unit declaration.> Certain program unit pragmas are defined to be @i. If a library unit pragma applies to a program unit, the program unit shall be a library unit. @s8<@i> 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> 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 @fas. ** Find the rest in the conflict file ** !corrigendum J.15.15(0) @dinsc This subclause defines pragmas that specify properties of units for distributed systems. @s8<@i> The following @fas are defined with the given forms: @xindent<@ @ @b Shared_Passive[(@i@fa)];> @xindent<@ @ @b Remote_Types[(@i@fa)];> @xindent<@ @ @b Remote_Call_Interface[(@i@fa)];> @xindent<@ @ @b All_Calls_Remote[(@i@fa)];> Each of these pragmas is a library unit pragma. @s8<@i> A @i 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 @fa 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 @fa 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 @fa 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 @fa 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. **************************************************************** From an informal review of the RM by John Barnes, March 7, 2021. 2.8 29/3 maybe a good idea not to use obsolete features in examples, that is pragma Pure or add comment saying obsolete ****************************************************************