CVS difference for ai05s/ai05-0229-1.txt
--- ai05s/ai05-0229-1.txt 2011/03/26 07:49:22 1.9
+++ ai05s/ai05-0229-1.txt 2011/03/31 06:48:05 1.10
@@ -1,4 +1,4 @@
-!standard 13.2(5) 11-03-25 AI05-0229-1/05
+!standard 13.2(5) 11-03-30 AI05-0229-1/06
!standard 13.11.3(5)
!standard B.3.3(4)
!standard E.4.1(8)
@@ -84,8 +84,9 @@
===pragma Pack: (the pragma is to be obsolescent)
-Change the title of clause 13.2 to "Packed types". [Could have used "Aspect Pack"
-instead, but this seems more meaningful, and more like the inline clause. - RLB]
+Change the title of clause 13.2 to "Packed types". [Editor's note: Could have used
+"Aspect Pack" instead, but this seems more meaningful, and more like the inline clause.
+Similar comments apply to all of the other clauses that were named "pragma Something".]
Change "packing" to "Pack" in 13.3(55.e), 13.3(72), 13.3(72.a), 13.1(7.g),
9.10(1/3), 9.10(1.c), 13.6(1).
@@ -94,7 +95,7 @@
Modify 13.2(1):
-Redundant[{The Pack aspect having the value True}[A pragma Pack] specifies that
+[Redundant: {The Pack aspect having the value True}[A pragma Pack] specifies that
storage minimization should be the main criterion when selecting the representation
of a composite type.]
@@ -131,19 +132,38 @@
Modify AARM Notes 13.2(9.b-d/2), replacing "pragma Pack" with "the Pack aspect".
+Modify A.1(37) to use the Pack aspect rather than the pragma:
+
+type String is array(Positive range <>) of Character{
+ with Pack};
+[ pragma Pack(String);]
+
+Modify A.1(42), A.1(42.1/2), B.4(12), B.4(16), B.4(20), B.4(29), B.5(12) to use the
+Pack aspect rather than the pragma as described above.
+
+In B.3(23), delete "pragma Pack" (it is bogus to have both Pack and Component_Size
+specified for the same type; Pack is ineffective in that case).
+
+Add "with Pack" to B.3(33), B.3(39.6/2), and B.3(39.14/2).
+
+Delete B.3(34), B.3(39.7/2), and B.3(39.15/2) [which are just pragma Pack].
+
Modify C.6(21):
If [a pragma Pack applies to]{the Pack aspect is True for} a type any
of ...
+AARM notes in 13.1 and 13.3 need modification from "pragma Pack" to "aspect Pack".
+
+
===pragma No_Return (the pragma is to be obsolescent)
-Change the title of clause 6.5.1 to "Non-returning procedures". [Could have used "Aspect No_Return" instead - RLB]
+Change the title of clause 6.5.1 to "Non-returning procedures".
Modify 6.5.1(1/2):
{Specifying aspect No_Return to have the value True}[A pragma No_Return] indicates that a procedure
-cannot return normally Redundant[; it may propagate an exception or loop forever].
+cannot return normally [Redundant:; it may propagate an exception or loop forever].
Delete 6.5.1(2-3/2). [Now in Annex J.]
@@ -158,7 +178,7 @@
an entity, the entity is said to be *non-returning*.
If directly specified, the aspect_definition shall be a static expression.
- Redundant [This aspect is never inherited;] if not directly specified, the
+ [Redundant: This aspect is never inherited;] if not directly specified, the
aspect is False.
Move 6.5.1(8/2) to this point (keeping the Static Semantics together).
@@ -186,9 +206,7 @@
===pragma Controlled: (the pragma is to be obsolescent)
-Change the title of clause 13.11.3 to "Controlling Storage Reclamation". [Could have
-used "Aspect Controlled" instead, but this seems more meaningful, and more like the inline
-clause. - RLB]
+Change the title of clause 13.11.3 to "Controlling Storage Reclamation".
Modify 13.11.3(1/2):
@@ -255,11 +273,12 @@
===pragma Discard_Names:
-[Editor's note: Can't get rid of this pragma; its use as a configuration pragma or to apply
-to all entities in a package specification cannot be modeled as an aspect.]
+[Editor's note: Can't get make this pragma obsolescent; its use as a configuration pragma or
+to apply to all entities in a package specification cannot be modeled as an aspect.
C.5: No changes needed for Discard_Names; the general wording for using representation
-pragmas as aspects applies here.
+pragmas as aspects applies here. But note that this is the only remaining representation
+pragma in the core.
Add an AARM Ramification after C.5(6): Representation pragmas are automatically aspects,
so Discard_Names can be used as an aspect_mark in an aspect_specification instead of
@@ -272,7 +291,7 @@
** Unchanged - TBD ** -- Assigned to Ed.
===pragma Atomic, Atomic_Components, Independent,
-Independent_Components, Volatile, Volatile_Components:
+Independent_Components, Volatile, Volatile_Components: (the pragmas are to be obsolescent)
C.6(14): No changes needed for Atomic, Atomic_Components, Independent,
Independent_Components, Volatile, Volatile_Components.
@@ -372,7 +391,7 @@
of a library unit is True, the library unit shall be a remote call
interface.
-Modify E/2/3(19/1):
+Modify E.2.3(19/1):
If [a pragma]{aspect} All_Calls_Remote [applies to]{is True for} a
given RCI library unit, ...
@@ -413,7 +432,7 @@
instances of that generic subprogram.
If directly specified, the aspect_definition shall be a static expression.
- Redundant [This aspect is never inherited;] if not directly specified, the
+ [Redundant: This aspect is never inherited;] if not directly specified, the
aspect is False.
Modify 6.3.2(6):
@@ -431,7 +450,7 @@
Other pragmas:
** Unchanged - TBD ** - Assigned to Steve
-===pragma Preelaborable_Initialization
+===pragma Preelaborable_Initialization (the pragma is to be obsolescent)
Replace 10.2.1(11.6/2):
@@ -476,28 +495,27 @@
True, and so on. That seems like it would involve a lot of opportunities for
errors, so I went with the minimal change (even though it doesn't make much
sense logically).]
+
+===pragma Interrupt_Handler and Attach_Handler (the pragma is to be obsolescent)
-** Unchanged - TBD **
-===pragma Interrupt_Handler
+Delete C.3.1(1-6) [Now in Annex J.]
Insert before C.3.1(7/3):
Static Semantics
-
-The Attach_Handler and Interrupt_Handler representation aspects may be specified
-on a parameterless protected procedure.
-When the Interrupt_Handler aspect is specified the aspect_definition is expected
-to be an expression of type Boolean. The expression shall be static with value
-True. When the Attach_Handler aspect_mark is specified, the aspect_definition is
-expected to the an expression of type Interrupts.Interrupt_Id.
-A pragma Interrupt_Handler specifies the Interrupt_Handler aspect for the
-protected procedure handler_name to have the value True. A pragma Attach_Handler
-specifies the Attach_Handler aspect for the protected procedure handler_name to
-have the value of the given expression Redundant[as evaluated at object creation
-time].
+ For a parameterless protected procedure, the following language-defined
+ representation aspects may be specified:
+ Interrupt_Handler
+ The type of aspect Interrupt_Handler is Boolean.
+ If directly specified, the aspect_definition shall be a static expression.
+ [Redundant: This aspect is never inherited;] if not directly specified, the
+ aspect is False.
+ Attach_Handler
+ The type of aspect Interrupt_Handler is Interrupts.Interrupt_Id.
+ [Redundant: This aspect is never inherited.]
-Delete the last sentence of C.3.1(7/3) [it is being moved down].
+Delete C.3.1(7/3). [Also in Annex J.]
Add after C.3.1(7/3):
@@ -505,15 +523,14 @@
protected procedure, the corresponding
protected_type_declaration or single_protected_declaration shall be a
library-level declaration and shall not be declared within a generic body.
-
-In addition to the places where Legality Rules normally apply (see 12.3), these
+In addition to the places where Legality Rules normally apply (see 12.3), this
rules also apply in the private part of an instance of a generic unit.
Replace C.3.1(9):
If the Interrupt_Handler aspect of a protected procedure is True,
then the procedure may be attached dynamically, as a handler, to interrupts (see
-C.3.2). Redundant[Such procedures are allowed to be attached to multiple
+C.3.2). [Redundant: Such procedures are allowed to be attached to multiple
interrupts.]
Replace C.3.1(10):
@@ -565,7 +582,7 @@
Modify C.3.1(19):
Notwithstanding what this subclause says elsewhere, the Attach_Handler and
-Interrupt_Handler pragmas {and aspects} are allowed to be used for other,
+Interrupt_Handler [pragmas]{aspects} are allowed to be used for other,
implementation defined, forms of interrupt handlers.
Modify C.3.1(22):
@@ -576,15 +593,15 @@
[Also, make similar changes to the AARM notes at the end of the clause.]
-** Unchanged - TBD **
-===pragma Storage_Size
+===pragma Storage_Size (the pragma is to be obsolescent)
-[Note: The existing attribute allows specification of Storage_Size for a task
+[Editor's note: The existing attribute allows specification of Storage_Size for a task
type *but* that attribute is obsolescent! Moreover, it would evaluate the
-expression too soon (when the type is frozen). I wrote specific wording to match
-the pragma. Not sure how to resolve the conflict with the obsolescent attribute,
-I used a TBH. Perhaps AI-183 needs to say something about not using "automatic"
-aspects if there is one with the same name explicitly defined??]
+expression too soon (when the type is frozen). My presumption is that this explicit
+wording overrides the "automatic" aspect implied by the obsolescent attribute.
+I handled this with a pair of AARM notes, since I don't want to rewrite the
+wording of an obsolescent attribute nor rewrite the aspect_specification wording
+for this unusual case.]
Modify 13.3(60):
@@ -601,151 +618,79 @@
Static Semantics
-The representation aspect Storage_Size may be specified for a
-task_type_declaration or a single_task_declaration. The value of the aspect is
-an expression.
+ For a task type (including the anonymous type of a single_task_definition),
+ the following language-defined representation aspect may be specified:
+ Storage_Size
+ The value of aspect Storage_Size is an expression, which shall be of
+ any integer type.
+
+[Editor's note: I would have used the shorter wording "single task", but that term is
+not defined by the Standard. We do use it in a few AARM notes, but that isn't much help.
+Thus I used the longer wording.]
-AARM To Be Honest: This definition conflicts with the "automatic" one for the
-obsolescent attribute Storage_Size. We intend for that "automatic" one to not be
+AARM To Be Honest: This definition somewhat conflicts with the "automatic" one for
+the obsolescent attribute Storage_Size. We intend for that "automatic" one to not be
used for that attribute.
-
-[Add an AARM note in J.9 to mention this.]
-
-Name Resolution Rules
-
-When the aspect Storage_Size is specified, the aspect_definition is an
-expression which is expected to be of any integer type.
-
-Dynamic Semantics
-
-When a task object with a specified Storage_Size is elaborated, the expression
-associated with the aspect is evaluated; the Storage_Size attribute of the newly
-created task object is at least the value of the expression.
-
-At the point of task object creation, or upon task activation, Storage_Error is
-raised if there is insufficient free storage to accommodate the requested
-Storage_Size.
-
-Delete 13.3(66-67), replacing them by:
-
-Static Semantics
-
-The pragma Storage_Size sets the Storage_Size aspect of the type defined by the
-immediately enclosing task_definition to the value of the expression of the
-pragma.
-
-
-** Unchanged - TBD **
-===pragma Relative_Deadline
-
-Delete the last sentence of D.2.6(6/2) [it follows from the aspect rules.]
-
-Add after D.2.6(9/2):
-
-The Relative_Deadline representation aspect may be specified on a
-task_type_declaration, a single_task_declaration, a subprogram_declaration. The
-value of the aspect is an expression.
-
-[Note: We have to use "subprogram_declaration" here, as aspects are not allowed
-in bodies. In the case of specifying this for the main subprogram, the pragma
-might be preferred to the aspect because a separate specification is not
-required.]
-
-When the aspect Relative_Deadline is specified, the aspect_definition is an
-expression which is expected to be of type Real_Time.Time_Span.
-
-The pragma Relative_Deadline sets the Relative_Deadline aspect of the enclosing
-task or subprogram to the relative_deadline_expression.
-
-Replace D.2.6(12/2):
-
-The Relative_Deadline aspect has no effect if it is specified for a subprogram
-other than the main subprogram.
-
-Modify D.2.6(13/2):
-
-The initial absolute deadline of a task {for which the}[containing pragma]
-Relative_Deadline {aspect is specified} is the value of Real_Time.Clock +
-[relative_deadline_]expression{ of the aspect}, where the call of
-Real_Time.Clock is made between task creation and the start of its activation.
-If there is no Relative_Deadline [pragma]{aspect} then the initial absolute
-deadline of a task is the value of Default_Deadline. [The environment task is
-also given an initial deadline by this rule.]
-
-** Unchanged - TBD **
-===pragma CPU
-
-[Editor's note: I've left the definition of the pragma, mainly because using the
-aspect is annoying for the main subprogram. See Relative_Deadline for more
-discussion.]
-
-Replace D.16(9/3):
-
-[Note: The original wording here is ambiguous.]
-
-When the aspect CPU is specified, the aspect_definition is an expression which
-is expected to be of type System.Multiprocessors.CPU_Range. The expected type
-for the expression of a pragma CPU is System.Multiprocessors.CPU_Range.
-
-Add after D.16(9/3):
+[Editor's note: Task types cannot be derived, so we don't have to worry about
+aspect inheritance, other than from task interfaces (a new possibility). Should we make
+specifying the aspect for those illegal?? The inabilility to derive also means we cannot
+run afoul of 13.1(10).]
-Static Semantics
+Delete 13.3(62-65) [Now in Annex J.]
-The CPU representation aspect may be specified on a task_type_declaration, a
-single_task_declaration, a subprogram_declaration. The value of the aspect is an
-expression.
+Replace 13.3(66) with:
-The pragma CPU sets the CPU aspect of the enclosing task or subprogram to the
-expression.
+When a task object is created, the expression (if any) associated with the Storage_Size
+aspect of its type is evaluated; the Storage_Size attribute of the newly created
+task object is at least the value of the expression.
-Delete the second sentence of D.16(10/3). [This follows from the rules for
-aspects.]
+AARM Ramification: If the Storage_Size aspect is not specified for the type of the
+task object, the value of the Storage_Size attribute is unspecified.
-Add to the end of D.16(11/3): If the CPU aspect is specified for a subprogram,
-the expression shall be static.
+Add after J.9(3/2):
-Modify D.16(12-4/3):
+AARM Ramification:
+When this attribute is specified with an attribute_definition_clause, the associated
+aspect is set to the value of the expression given in the attribute_definition_clause.
+This value is therefore the same for all objects of the type; in particular, it is
+not re-evaluated when objects are created. This is different than when the aspect
+is specified with an aspect_specification (see 13.3).
-The expression [of a CPU pragma that appears in a task_definition]{specifed for
-the CPU aspect of a task} is evaluated for each task object (see 9.1). The CPU
-value is then associated with the task object whose [task_definition contains
-the pragma]{task declaration specifies the aspect}.
-[A CPU pragma]{The CPU aspect} has no effect if it {is specified for a
-subprogram}[occurs immediately within the declarative_part of a subprogram_body]
-other than the main subprogram; the CPU value is not associated with any task.
+===pragma Interrupt_Priority, Priority (the pragmas are to be obsolescent)
-The CPU value is associated with the environment task if [the pragma appears in
-the declarative_part of]{the CPU aspect is specified for} the main subprogram.
-If [a pragma CPU does not apply to]{the CPU aspect is not specified for} the
-main subprogram it is implementation defined on which processor the environment
-task executes.
+[Editor's Note: I'd much prefer that there was only one aspect here, but the rules about
+converting to subtype Any_Priority vs. to subtype Priority at evaluation time force
+two aspects. That's because these aspects are expressions that are evaluated when
+the task (or protected) object is elaborated, not values evaluated at the freezing point.
+Personally, I'd drop the two subtypes, but one presumes that there is some value to the
+bifrucation and in any case it is 30 years too late for that.]
-** Unchanged - TBD **
-===pragma Interrupt_Priority, Priority
+Delete D.1(2-7) [Moved to Annex J.]
Add after D.1(5):
Static Semantics
-
-The Priority and Interrupt_Priority representation aspects may be specified on a
-task_type_declaration, a single_task_declaration, a subprogram_declaration. The
-value of the aspects is an expression.
-
-The pragma Priority sets the Priority aspect of the enclosing task or subprogram
-to the expression. The pragma Interrupt_Priority sets the Interrupt_Priority
-aspect of the enclosing task or subprogram to the expression, if any. If there
-is no expression in an Interrupt_Priority pragma, the Interrupt_Priority aspect
-has the value Interrupt_Priority'Last.
-Add to the end of D.1(6):
+ For a task type (including the anonymous type of a single_task_definition),
+ protected type (including the anonymous type of a single_protected_definition),
+ or subprogram, the following language-defined representation aspects may be specified:
+ Priority
+ The value of aspect Priority is an expression, which shall be of
+ type Integer.
+ Interrupt_Priority
+ The value of aspect Interrupt_Priority is an expression, which shall be of
+ type Integer.
+
+[Editor's Note: See the comment about "single task" in Storage_Size.]
+
+[Editor's note: Task types and protected types cannot be derived, and subprograms never
+inherit aspects, so we don't have to worry about aspect inheritance, other than from
+synchronized interfaces (a new possibility). Should we make specifying the aspects for
+those illegal?? The inabilility to derive also means we cannot
+run afoul of 13.1(10).]
-When the aspect Priority or Interrupt_Priority is specified, the
-aspect_definition is an expression which is expected to be of type Integer.
-
-Delete the last sentence of D.1(7) [handled below]
-
Replace D.1(8):
If the Priority aspect is specified for a subprogram, the expression shall be static,
@@ -756,9 +701,11 @@
At most one of the Priority and Interrupt_Priority aspects may be specified for
a given entity.
-AARM Ramification: This includes specifying via pragmas.
+AARM Ramification: This includes specifying via pragmas (see J.15.7).
-Delete D.1(13). [This is covered by other wording.]
+Delete D.1(13). [This is covered by other wording, and seems to conflict with D.1(17)
+anyway. The definition of the value of the pragma is never used anywhere, so far
+as I can tell.]
Replace D.1(14):
@@ -767,13 +714,14 @@
other than the main subprogram{; the Priority value is not associated with any
task}.
-[Note: We added the last part as a clarification for CPU, it should be here,
-too.]
+[Editor's Note: We added the last part as a clarification for aspect CPU, it
+should be here, too.]
Modify D.1(16):
-The effect of specifying [such a pragma in]{a Priority or Interrupt_Priority
-for} a protected_definition is discussed in D.3.
+The effect of specifying [such a pragma in a protected_definition]{a Priority or
+Interrupt_Priority aspect for a protected type or single_protected_definition}
+is discussed in D.3.
Modify D.1(17):
@@ -821,13 +769,102 @@
Attach_Handler specified, then the initial priority of the corresponding
protected object is System.Priority'Last.
+
+==pragma Relative_Deadline (the pragma is to be obsolescent)
+
+Delete D.2.6(3-6/2) [Now in Annex J.]
+
+Add after D.2.6(9/2):
+
+ For a task type (including the anonymous type of a single_task_definition)
+ or subprogram, the following language-defined representation aspect may be
+ specified:
+ Relative_Deadline
+ The value of aspect Relative_Deadline is an expression, which shall be of
+ type Real_Time.Time_Span.
+
+[Editor's Note: See the comment about "single task" in Storage_Size.]
+
+[Editor's note: Task types cannot be derived, and subprograms never
+inherit aspects, so we don't have to worry about aspect inheritance, other than from
+task interfaces (a new possibility). Should we make specifying the aspects for
+those illegal?? The inabilility to derive also means we cannot
+run afoul of 13.1(10).]
+
+Replace D.2.6(12/2):
+
+The Relative_Deadline aspect has no effect if it is specified for a subprogram
+other than the main subprogram.
+
+Modify D.2.6(13/2):
+
+The initial absolute deadline of a task {for which aspect}[containing pragma]
+Relative_Deadline {is specified} is the value of Real_Time.Clock +
+[relative_deadline_]expression{ that is the value of the aspect}, where {this
+entire expression, including }the call of Real_Time.Clock{, is evaluated}
+[is made] between task creation and the start of its activation. If there is no
+Relative_Deadline pragma then the initial absolute
+deadline of a task is the value of Default_Deadline. [Redundant: The
+environment task is also given an initial deadline by this rule.]
+
+[Editor's note: The original wording did not specify when the deadline expression
+is evaluated. Since it is per-object, it also has to be evaluated when the
+task is created (roughly).]
+
+===pragma CPU (the pragma is to be born obsolescent)
+
+Delete D.16(7-9/3) [Now in Annex J.]
+
+Add after D.16(9/3):
+
+Static Semantics
+
+ For a task type (including the anonymous type of a single_task_definition) or
+ subprogram, the following language-defined representation aspect may be specified:
+ CPU
+ The value of aspect CPU is an expression, which shall be of
+ type System.Multiprocessors.CPU_Range.
+
+[Editor's Note: See the comment about "single task" in Storage_Size.]
+
+[Editor's note: Task types cannot be derived, and subprograms never
+inherit aspects, so we don't have to worry about aspect inheritance, other than from
+task interfaces (a new possibility). Should we make specifying the aspects for
+those illegal?? The inabilility to derive also means we cannot
+run afoul of 13.1(10).]
-===pragma Implemented
+Delete D.16(10/3). [Now in Annex J.]
+
+Replace D.16(11/3) with:
+If the CPU aspect is specified for a subprogram, the expression shall be static.
+
+Modify D.16(12-4/3):
+
+The expression [of a CPU pragma that appears in a task_definition]{specifed for
+the CPU aspect of a task} is evaluated for each task object (see 9.1). The CPU
+value is then associated with the task object whose [task_definition contains
+the pragma]{task declaration specifies the aspect}.
+
+[A CPU pragma]{The CPU aspect} has no effect if it {is specified for a
+subprogram}[occurs immediately within the declarative_part of a subprogram_body]
+other than the main subprogram; the CPU value is not associated with any task.
+The CPU value is associated with the environment task if [the pragma appears in
+the declarative_part of]{the CPU aspect is specified for} the main subprogram.
+If [a pragma CPU does not apply to]{the CPU aspect is not specified for} the
+main subprogram it is implementation defined on which processor the environment
+task executes.
+
+===pragma Dispatching_Domain (the pragma is to be born obsolescent)
+
+See AI05-0167-1 for the aspect.
+
+===pragma Implemented (there will not be a pragma)
+
See AI05-0215-1.
** Unchanged - TBD ** -- Assigned to Tucker.
-===pragmas Convention, Export, Import:
+===pragmas Convention, Export, Import: (the pragmas are to be obsolescent)
Modify B.1(28) as follows:
@@ -847,13 +884,7 @@
defaults to Ada for a user-declared entity, unless specified otherwise
in this International Standard (see 6.3.1).]}
-===pragma Dispatching_Domain
-
-See AI05-0167-1.
-** TBD -- born obsolescent pragma.
-
-
Add a new clause to Annex J:
[Note: The subclauses will be rearranged in alphabetical order - at the last
@@ -870,7 +901,8 @@
Syntax
-The form of a pragma Pack is as follows:
+The form of a pragma Pack, which is a representation pragma (see 13.1),
+is as follows:
pragma Pack(*first_subtype_*local_name);
Legality Rules
@@ -880,8 +912,8 @@
Static Semantics
-Pragma Pack is a representation pragma that specifies that the Pack aspect
-(see 13.2) for the type denoted by *first_subtype_*local_name has the value True.
+Pragma Pack specifies that the Pack aspect (see 13.2) for the type
+denoted by *first_subtype_*local_name has the value True.
J.15.2 Pragma Inline
@@ -896,14 +928,23 @@
The pragma shall apply to one or more callable entities or generic
subprograms.
+
+[Editor's Note: "apply" comes from the definition of program unit pragma.
-[Editor's Note: "apply" comes from the definition of program unit pragma.]
+Alternatively, we could have said:
+"The name of a pragma Inline shall apply to one or more callable entities or generic
+subprograms that may have aspect Inline specified." which allows us to
+depend on the Legality Rules of the aspect. In that case, we'd want to swap
+the Legality Rules and Static Semantics sections. I didn't do this because
+it is more wordy than just repeating the only Legality Rule of the aspect.]
Static Semantics
Pragma Inline specifies that the Inline aspect (see 6.3.2) for each
entity denoted by each name given in the pragma has the value True.
+[Editor's note: The following AARM notes are moving from 6.3.2 to here.]
+
AARM Ramification: Note that inline expansion is desired no matter
what name is used in the call. This allows one to request inlining
for only one of several overloaded subprograms as follows:
@@ -955,7 +996,7 @@
Legality Rules
Each procedure_local_name shall denote one or more procedures or generic procedures.
-Redundant[The procedure_local_name shall not denote a null procedure nor an instance
+[Redundant: The procedure_local_name shall not denote a null procedure nor an instance
of a generic unit.]
Static Semantics
@@ -967,7 +1008,7 @@
Syntax
-The form of a pragma Controlled is as follows:
+The form of a pragma Controlled, which is a representation pragma (see 13.1), is as follows:
pragma Controlled(first_subtype_local_name);
@@ -977,7 +1018,7 @@
Static Semantics
-A pragma Controlled is a representation pragma that specifies the Controlled aspect (see 13.11.3)
+A pragma Controlled specifies that the Controlled aspect (see 13.11.3)
for the type denoted by *first_subtype_*local_name has the value True.
@@ -985,7 +1026,7 @@
Syntax
-The form of a pragma Unchecked_Union is as follows:
+The form of a pragma Unchecked_Union, which is a representation pragma (see 13.1), is as follows:
pragma Unchecked_Union (first_subtype_local_name);
@@ -996,7 +1037,7 @@
Static Semantics
-A pragma Unchecked_Union is a representation pragma that specifies the Unchecked_Union aspect
+A pragma Unchecked_Union specifies that the Unchecked_Union aspect
(see B.3.3) for the type denoted by *first_subtype_*local_name has the value True.
@@ -1004,22 +1045,170 @@
Syntax
-The form of a pragma Asynchronous is as follows:
+The form of a pragma Asynchronous, which is a representation pragma (see 13.1), is as follows:
pragma Asynchronous(local_name);
Static Semantics
-For an implementation that supports Annex E, a pragma Asynchronous is a representation pragma
-that specifies the Asynchronous aspect (see E.4.1) for the procedure or type denoted by local_name
+For an implementation that supports Annex E, a pragma Asynchronous specifies that
+the Asynchronous aspect (see E.4.1) for the procedure or type denoted by local_name
has the value True.
Legality Rules
-The local_name of a pragma Asynchronous shall denote a declaration that is may have aspect
+The local_name of a pragma Asynchronous shall denote a declaration that may have aspect
Asynchronous specified.
+J.15.7 Pragma Priority and Pragma Interrupt_Priority
+
+Syntax
+
+The form of a pragma Priority is as follows:
+
+ pragma Priority(expression);
+
+The form of a pragma Interrupt_Priority is as follows:
+
+ pragma Interrupt_Priority[(expression)];
+
+Name Resolution Rules
+
+The expected type for the expression in a Priority or Interrupt_Priority pragma is Integer.
+
+Legality Rules
+
+A Priority pragma is allowed only immediately within a task_definition, a protected_definition,
+or the declarative_part of a subprogram_body. An Interrupt_Priority pragma is allowed only
+immediately within a task_definition or a protected_definition. At most one such pragma shall
+appear within a given construct.
+
+For a Priority pragma that appears in the declarative_part of a subprogram_body, the
+expression shall be static, and its value shall be in the range of System.Priority.
+
+Static Semantics
+
+For an implementation that supports Annex D, a pragma Priority specifies the value of the Priority
+aspect (see D.1) and a pragma Interrupt_Priority specifies the value of the Interrupt_Priority aspect
+as follows:
+* If the pragma appears in a task_definition, the expression is associated with the aspect for the
+ task type or single_task_definition that contains the pragma;
+* If the pragma appears in a protected_definition, the expression is associated with the aspect
+ for the protected type or single_protected_definition that contains the pragma;
+* If the pragma appears in the declarative part of a subprogram_body, the expression is associated
+ with the aspect for the subprogram that contains the pragma.
+
+If there is no expression in an Interrupt_Priority pragma, the Interrupt_Priority aspect
+has the value Interrupt_Priority'Last.
+
+J.15.8 pragma CPU
+
+AARM Discussion: This pragma is born obsolescent; it is defined to provide consistency with
+existing real-time pragmas.
+
+Syntax
+
+The form of a pragma CPU is as follows:
+ pragma CPU (expression);
+
+Name Resolution Rules
+
+The expected type for the expression of a pragma CPU is System.Multiprocessors.CPU_Range.
+
+Legality Rules
+
+A CPU pragma is allowed only immediately within a task_definition, or the declarative_part of a
+subprogram_body. At most one such pragma shall appear within a given construct.
+
+For a CPU pragma that appears in the declarative_part of a subprogram_body, the expression shall
+be static.
+
+Static Semantics
+
+For an implementation that supports Annex D, a pragma CPU specifies the value of the CPU
+aspect (see D.16). If the pragma appears in a task_definition, the expression is associated with
+the aspect for the task type or single_task_definition that contains the pragma; otherwise,
+the expression is associated with the aspect for the subprogram that contains the pragma.
+
+J.15.9 pragma Relative_Deadline
+
+Syntax
+The form of a pragma Relative_Deadline is as follows:
+ pragma Relative_Deadline (relative_deadline_expression);
+
+Name Resolution Rules
+
+The expected type for relative_deadline_expression is Real_Time.Time_Span.
+
+Legality Rules
+
+A Relative_Deadline pragma is allowed only immediately within a task_definition or the
+declarative_part of a subprogram_body. At most one such pragma shall appear within a given
+construct.
+
+Static Semantics
+
+For an implementation that supports Annex D, a pragma Relative_Deadline specifies the value of
+the Relative_Deadline aspect (see D.2.6). If the pragma appears in a task_definition, the expression
+is associated with the aspect for the task type or single_task_definition that contains the pragma;
+otherwise, the expression is associated with the aspect for the subprogram that contains the pragma.
+
+J.15.10 pragma Storage_Size
+
+Syntax
+
+The form of a pragma Storage_Size is as follows:
+
+ pragma Storage_Size(expression);
+
+A pragma Storage_Size is allowed only immediately within a task_definition.
+
+Name Resolution Rules
+
+The expression of a pragma Storage_Size is expected to be of any integer type.
+
+Static Semantics
+
+The pragma Storage_Size sets the Storage_Size aspect of the type defined by the
+immediately enclosing task_definition to the value of the expression of the
+pragma.
+
+J.15.11 Pragmas Interrupt_Handler and Attach_Handler
+
+The form of a pragma Interrupt_Handler is as follows:
+ pragma Interrupt_Handler(handler_name);
+
+The form of a pragma Attach_Handler is as follows:
+ pragma Attach_Handler(handler_name, expression);
+
+Name Resolution Rules
+
+For the Interrupt_Handler and Attach_Handler pragmas, the handler_name shall
+resolve to denote a protected procedure with a parameterless profile.
+
+For the Attach_Handler pragma, the expected type for the expression is
+Interrupts.Interrupt_Id (see C.3.2).
+
+Legality Rules
+
+The Attach_Handler and Interrupt_Handler pragmas are only allowed immediately
+within the protected_definition where the corresponding subprogram is declared.
+The corresponding protected_type_declaration or single_protected_declaration shall
+be a library-level declaration, and shall not be declared within a generic body.
+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.
+
+Static Semantics
+
+A pragma Interrupt_Handler specifies the Interrupt_Handler aspect for the
+protected procedure handler_name to have the value True. A pragma Attach_Handler
+specifies the Attach_Handler aspect for the protected procedure handler_name to
+have the value of the given expression [Redundant: as evaluated at object creation
+time].
+
+
+
*** Additional obsolescent pragmas here ***
@@ -1071,9 +1260,21 @@
Or it could have just one parameter, the entity, and the type of the aspect is
Boolean (True/False means the pragma is present/absent).
+
-Following is a list of all Ada pragmas, listed in
+The use of aspects as compared to pragmas is strongly preferred for subprograms (as
+there are no overloading problems to worry about; the target subprogram is obvious).
+The use of aspects is also preferred for types and objects, as the pragmas can
+get separated from the declarations and the declarations are (usually) short.
+There is no clear-cut decision for aspects applying to packages or other entities.
+
+Since we want to encourage the use of aspects, we make pragmas that can
+be replaced by aspects obsolescent, with the exception of pragmas that are
+primarily used on packages.
+
+Following is a list of all Ada pragmas, listed in categories.
+
----------------
Boolean representation aspects:
@@ -1100,11 +1301,6 @@
pragma Unchecked_Union (first_subtype_local_name); - See B.3.3.
-Note: For representation pragmas, 13.1(8/3) specifies that the
-pragma specifies an aspect and the name of that aspect. Thus, we don't need
-any wording in these pragmas about "aspects of representation"; we get rid
-of extra such wording for consistency.
-
----------------
Pragmas that could be Boolean operational or representation aspects:
@@ -1159,13 +1355,13 @@
----------------
Pragmas that could be other (normal) operational or representation aspects
-if we have a mechanism for "identifiers specific to an aspect":
+using the mechanism for "identifiers specific to an aspect":
pragma Convention([Convention =>] convention_identifier,[Entity =>]
local_name); - See B.1.
-- Note that the parameters are backwards
-pragma Implemented(procedure_local_name, implementation_kind); - See 9.5.
+pragma Implemented(procedure_local_name, implementation_kind); - See 9.5 (and AI05-0030-2).
pragma Export(
[Convention =>] convention_identifier, [Entity =>] local_name
Questions? Ask the ACAA Technical Agent