J.15 Aspect-related Pragmas

danger

This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue

1/3

Pragmas can be used as an alternative to aspect_specifications to specify certain aspects.

Name Resolution Rules

2/5

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.

2.a/5

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

3/5

A program unit pragma shall appear in one of these places:

4/5

• 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.
  

4.a/5

ramification

The name has to denote the immediately preceding library_unit_declaration.

5/5

• {8652/0033} 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.
  

5.a/5

ramification

The argument is optional in this case.

6/5

• 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.
  

6.a/5

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.

7/5

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.

7.a/5

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

8/5

{8652/0034} 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

9/5

{8652/0034} 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.

9.a/5

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.

Wording Changes from Ada 2005

9.b/3

This subclause is new. Many existing pragmas have been converted into aspects; the pragmas have moved here.

9.c/5

correction

A library unit pragma must apply directly to a library unit, even if no name is given in the pragma.

Wording Changes from Ada 2012

9.d/5

The terms “program unit pragma” and “library unit pragma” were moved here as all of the pragmas that use these terms are now in this annex.

J.15.1 Pragma Inline

Syntax

1/3

The form of a pragma Inline, which is a program unit pragma (see 10.1.5), is as follows:

2/3

pragma Inline (name{, name});

Legality Rules

3/3

The pragma shall apply to one or more callable entities or generic subprograms.

Static Semantics

4/3

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.

4.a/3

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:

4.b/3

package IO is
   procedure Put(X : in Integer);
   procedure Put(X : in String);
   procedure Put(X : in Character);
private
   procedure Character_Put(X : in Character) renames Put;
   pragma Inline(Character_Put);
end IO;

4.c/3
with IO; use IO;
procedure Main is
   I : Integer;
   C : Character;
begin
   ...
   Put(C); -- Inline expansion is desired.
   Put(I); -- Inline expansion is NOT desired.
end Main;

Implementation Permissions

5/3

An implementation may allow a pragma Inline that has an argument which is a direct_name denoting a subprogram_body of the same declarative_part.

5.a/3

reason

This is allowed for Ada 83 compatibility. This is only a permission as this usage was considered obsolescent even for Ada 95.

5.b/3

discussion

We only need to allow this in declarative_parts, because a body is only allowed in another body, and these all have declarative_parts.

6/5

NOTE The name in a pragma Inline can denote more than one entity in the case of overloading. Such a pragma applies to all of the denoted entities.

Incompatibilities With Ada 83

6.a/3

A pragma Inline cannot refer to a subprogram_body outside of that body. The pragma can be given inside of the subprogram body. Ada 2005 adds an Implementation Permission to allow this usage for compatibility (and Ada 95 implementations also can use this permission), but implementations do not have to allow such pragmas.

Extensions to Ada 83

6.b/3

A pragma Inline is allowed inside a subprogram_body if there is no corresponding subprogram_declaration. This is for uniformity with other program unit pragmas.

Extensions to Ada 95

6.c/3

correction

Amendment Implementations are allowed to let Pragma Inline apply to a subprogram_body.

Wording Changes from Ada 2005

6.d/3

This subclause is new. Pragma Inline was moved here from 6.3.2; aspect Inline lives there now.

J.15.2 Pragma No_Return

Syntax

1/3

The form of a pragma No_Return, which is a representation pragma (see 13.1), is as follows:

2/5

pragma No_Return (subprogram_local_name{, subprogram_local_name});

Legality Rules

3/5

Each subprogram_local_name shall denote one or more subprograms or generic subprograms. [The subprogram_local_name shall not denote a null procedure nor an instance of a generic unit.]

Static Semantics

4/5

Pragma No_Return specifies that the No_Return aspect (see 6.5.1) for each subprogram denoted by each local_name given in the pragma has the value True.

Wording Changes from Ada 2005

4.a/3

This subclause is new. Pragma No_Return was moved here from 6.5.1; aspect No_Return lives there now.

Wording Changes from Ada 2012

4.b/5

This subclause is new. Pragma No_Return was moved here from 6.5.1; aspect No_Return lives there now.

J.15.3 Pragma Pack

Syntax

1/3

The form of a pragma Pack, which is a representation pragma (see 13.1), is as follows:

2/3

pragma Pack (first_subtype_local_name);

Legality Rules

3/3

The first_subtype_local_name of a pragma Pack shall denote a composite subtype.

Static Semantics

4/3

Pragma Pack specifies that the Pack aspect (see 13.2) for the type denoted by first_subtype_local_name has the value True.

Wording Changes from Ada 2005

4.a/3

This subclause is new. Pragma Pack was moved here from 13.2; aspect Pack lives there now.

J.15.4 Pragma Storage_Size

Syntax

1/3

The form of a pragma Storage_Size is as follows:

2/3

pragma Storage_Size (expression);

3/3

A pragma Storage_Size is allowed only immediately within a task_definition.

Name Resolution Rules

4/3

The expression of a pragma Storage_Size is expected to be of any integer type.

Static Semantics

5/3

The pragma Storage_Size sets the Storage_Size aspect (see 13.3) of the type defined by the immediately enclosing task_definition to the value of the expression of the pragma.

Wording Changes from Ada 2005

5.a/3

This subclause is new. Pragma Storage_Size was moved here from 13.3; aspect Storage_Size lives there now.

J.15.5 Interfacing Pragmas

Syntax

1/3

An interfacing pragma is a representation pragma that is one of the pragmas Import, Export, or Convention. Their forms are as follows:

2/3

pragma Import(
[Convention =>] convention_identifier, [Entity =>] local_name
[, [External_Name =>] external_name_string_expression]
[, [Link_Name =>] link_name_string_expression]);

3/3

pragma Export(
[Convention =>] convention_identifier, [Entity =>] local_name
[, [External_Name =>] external_name_string_expression]
[, [Link_Name =>] link_name_string_expression]);

4/3

pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name);

5/3

For pragmas Import and Export, the argument for Link_Name shall not be given without the pragma_argument_identifier unless the argument for External_Name is given.

Name Resolution Rules

6/3

The expected type for an external_name_string_expression and a link_name_string_expression in an interfacing pragma is String.

Legality Rules

7/3

The convention_identifier of an interfacing pragma shall be the name of a convention (see B.1).

8/3

A pragma Import shall be the completion of a declaration. Notwithstanding any rule to the contrary, a pragma Import may serve as the completion of any kind of (explicit) declaration if supported by an implementation for that kind of declaration. If a completion is a pragma Import, then it shall appear in the same declarative_part, package_specification, task_definition, or protected_definition as the declaration. For a library unit, it shall appear in the same compilation, before any subsequent compilation_units other than pragmas. If the local_name denotes more than one entity, then the pragma Import is the completion of all of them.

9/3

The external_name_string_expression and link_name_string_expression of a pragma Import or Export shall be static.

10/3

The local_name of each of these pragmas shall denote a declaration that may have the similarly named aspect specified.

Static Semantics

11/3

An interfacing pragma specifies various aspects of the entity denoted by the local_name as follows:

12/3

• The Convention aspect (see B.1) is convention_identifier.
  
13/3
• A pragma Import specifies that the Import aspect (see B.1) is True.
  
14/3
• A pragma Export specifies that the Export aspect (see B.1) is True.
  
15/3
• For both pragma Import and Export, if an external name is given in the pragma, the External_Name aspect (see B.1) is specified to be external_name_string_expression. If a link name is given in the pragma, the Link_Name aspect (see B.1) is specified to be the link_name_string_expression.
  

Wording Changes from Ada 2005

15.a/3

This subclause is new. Pragmas Import, Export, and Convention were moved here from B.1; aspects Import, Export, Convention, Link_Name, and External_Name live there now.

J.15.6 Pragma Unchecked_Union

Syntax

1/3

The form of a pragma Unchecked_Union, which is a representation pragma (see 13.1), is as follows:

2/3

pragma Unchecked_Union (first_subtype_local_name);

Legality Rules

3/3

The first_subtype_local_name of a pragma Unchecked_Union shall denote an unconstrained discriminated record subtype having a variant_part.

Static Semantics

4/3

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.

Wording Changes from Ada 2005

4.a/3

This subclause is new. Pragma Unchecked_Union was moved here from B.3.3; aspect Unchecked_Union lives there now.

J.15.7 Pragmas Interrupt_Handler and Attach_Handler

Syntax

1/3

The form of a pragma Interrupt_Handler is as follows:

2/3

pragma Interrupt_Handler (handler_name);

3/3

The form of a pragma Attach_Handler is as follows:

4/3

pragma Attach_Handler (handler_name, expression);

Name Resolution Rules

5/3

For the Interrupt_Handler and Attach_Handler pragmas, the handler_name shall resolve to denote a protected procedure with a parameterless profile.

6/3

For the Attach_Handler pragma, the expected type for the expression is Interrupts.Interrupt_Id (see C.3.2).

Legality Rules

7/3

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.

7.a/3

discussion

In the case of a protected_type_declaration, an object_declaration of an object of that type need not be at library level.

7.b/3

We cannot allow these pragmas in a generic body, because legality rules are not checked for instance bodies, and these should not be allowed if the instance is not at the library level. The protected types can be declared in the private part if this is desired. Note that while the 'Access to use the handler would provide the check in the case of Interrupt_Handler, there is no other check for Attach_Handler. Since these pragmas are so similar, we want the rules to be the same.

Static Semantics

8/3

For an implementation that supports Annex C, a pragma Interrupt_Handler specifies the Interrupt_Handler aspect (see C.3.1) for the protected procedure handler_name to have the value True. For an implementation that supports Annex C, a pragma Attach_Handler specifies the Attach_Handler aspect (see C.3.1) for the protected procedure handler_name to have the value of the given expression[ as evaluated at object creation time].

Incompatibilities With Ada 2005

8.a/3

correction

Added missing generic contract wording for the pragma Attach_Handler and Interrupt_Handler. This means that nested instances with these pragmas in the private part are now illegal. This is not likely to occur in practice.

Wording Changes from Ada 2005

8.b/3

This subclause is new. Pragmas Interrupt_Handler and Attach_Handler were moved here from C.3.1; aspects Interrupt_Handler and Attach_Handler live there now.

J.15.8 Shared Variable Pragmas

Syntax

1/5

The following pragmas are defined with the given forms:

2/3

pragma Atomic (local_name);

3/3

pragma Volatile (local_name);

4/3

pragma Independent (component_local_name);

5/3

pragma Atomic_Components (array_local_name);

6/3

pragma Volatile_Components (array_local_name);

7/3

pragma Independent_Components (local_name);

7.a/3

discussion

Pragmas Independent and Independent_Components are born obsolescent; they are defined to provide consistency with the existing shared variable pragmas. As with all obsolescent features, these pragmas are not optional; all Ada implementations need to implement them. Also note that these pragmas were defined as a Correction; as such, they are expected to be implemented as part of Ada 2005 implementations (and they would not be obsolescent there).

Name Resolution Rules

8/3

The local_name in an Atomic or Volatile pragma shall resolve to denote either an object_declaration, a noninherited component_declaration, or a full_type_declaration. The component_local_name in an Independent pragma shall resolve to denote a noninherited component_declaration. The array_local_name in an Atomic_Components or Volatile_Components pragma shall resolve to denote the declaration of an array type or an array object of an anonymous type. The local_name in an Independent_Components pragma shall resolve to denote the declaration of an array or record type or an array object of an anonymous type.

Static Semantics

9/3

These pragmas are representation pragmas (see 13.1). Each of these pragmas specifies that the similarly named aspect (see C.6) of the type, object, or component denoted by its argument is True.

Legality Rules

10/3

The local_name of each of these pragmas shall denote a declaration that may have the similarly named aspect specified.

Wording Changes from Ada 2005

10.a/3

This subclause is new. These pragmas were moved here from C.6; various aspects live there now.

J.15.9 Pragma CPU

0.a/3

discussion

This pragma is born obsolescent; it is defined to provide consistency with existing real-time pragmas. As with all obsolescent features, this pragma is not optional; all Ada implementations need to implement it.

Syntax

1/3

The form of a pragma CPU is as follows:

2/3

pragma CPU (expression);

Name Resolution Rules

3/3

The expected type for the expression of a pragma CPU is System.Multiprocessors.CPU_Range.

Legality Rules

4/5

A CPU pragma is allowed only immediately within a task_definition, protected_definition, or the declarative_part of a subprogram_body.

5/3

For a CPU pragma that appears in the declarative_part of a subprogram_body, the expression shall be static.

Static Semantics

6/5

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_declaration 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_declaration that contains the pragma. Otherwise, the expression is associated with the aspect for the subprogram that contains the pragma.

Extensions to Ada 2005

6.a/3

Pragma CPU is new.

J.15.10 Pragma Dispatching_Domain

0.a/3

discussion

This pragma is born obsolescent; it is defined to provide consistency with existing real-time pragmas. As with all obsolescent features, this pragma is not optional; all Ada implementations need to implement it.

Syntax

1/3

The form of a pragma Dispatching_Domain is as follows:

2/3

pragma Dispatching_Domain (expression);

Name Resolution Rules

3/3

The expected type for the expression is System.Multiprocessors.Dispatching_Domains.Dispatching_Domain.

Legality Rules

4/3

A Dispatching_Domain pragma is allowed only immediately within a task_definition.

Static Semantics

5/3

For an implementation that supports Annex D, a pragma Dispatching_Domain specifies the value of the Dispatching_Domain aspect (see D.16.1). The expression is associated with the aspect for the task type or single_task_declaration that contains the pragma.

Extensions to Ada 2005

5.a/3

Pragma Dispatching_Domain is new.

J.15.11 Pragmas Priority and Interrupt_Priority

Syntax

1/3

The form of a pragma Priority is as follows:

2/3

pragma Priority (expression);

3/3

The form of a pragma Interrupt_Priority is as follows:

4/3

pragma Interrupt_Priority [(expression);]

Name Resolution Rules

5/3

The expected type for the expression in a Priority or Interrupt_Priority pragma is Integer.

Legality Rules

6/3

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.

7/3

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

8/3

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:

9/3

• If the pragma appears in a task_definition, the expression is associated with the aspect for the task type or single_task_declaration that contains the pragma;
  
10/3
• If the pragma appears in a protected_definition, the expression is associated with the aspect for the protected type or single_protected_declaration that contains the pragma;
  
11/3
• 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.
  

12/3

If there is no expression in an Interrupt_Priority pragma, the Interrupt_Priority aspect has the value Interrupt_Priority'Last.

Wording Changes from Ada 2005

12.a/3

This subclause is new. Pragmas Interrupt_Priority and Priority were moved here from D.1; aspects Interrupt_Priority and Priority live there now.

J.15.12 Pragma Relative_Deadline

Syntax

1/3

The form of a pragma Relative_Deadline is as follows:

2/3

pragma Relative_Deadline (relative_deadline_expression);

Name Resolution Rules

3/3

The expected type for a relative_deadline_expression is Real_Time.Time_Span.

Legality Rules

4/3

A Relative_Deadline pragma is allowed only immediately within a task_definition or the declarative_part of a subprogram_body.

Static Semantics

5/3

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_declaration that contains the pragma; otherwise, the expression is associated with the aspect for the subprogram that contains the pragma.

Wording Changes from Ada 2005

5.a/3

This subclause is new. Pragma Relative_Deadline was moved here from D.2.6; aspect Relative_Deadline lives there now.

J.15.13 Pragma Asynchronous

Syntax

1/3

The form of a pragma Asynchronous, which is a representation pragma (see 13.1), is as follows:

2/3

pragma Asynchronous (local_name);

Static Semantics

3/3

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

4/3

The local_name of a pragma Asynchronous shall denote a declaration that may have aspect Asynchronous specified.

Wording Changes from Ada 2005

4.a/3

This subclause is new. Pragma Asynchronous was moved here from E.4.1; aspect Asynchronous lives there now.

J.15.14 Elaboration Control Pragmas

1/5

This subclause defines pragmas that specify aspects that help control the elaboration order of library_items.

1.a/5

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

2/5

The following pragmas are defined with the given forms:

3/5

pragma Preelaborate[(library_unit_name)];

4/5

pragma Preelaborable_Initialization(direct_name);

5/5

pragma Pure[(library_unit_name)];

6/5

pragma Elaborate_Body[(library_unit_name)];

7/5

Pragmas Preelaborate, Pure, and Elaborate_Body are library unit pragmas.

7.a/5

ramification

Pragma Preelaborable_Initialization is not a library unit pragma.

Static Semantics

8/5

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.

9/5

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.

10/5

A pragma Elaborate_Body specifies that [a library unit requires a completion, namely that] the Elaborate_Body aspect (see 10.2.1) of the library unit is True.

Legality Rules

11/5

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.

12/5

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 also apply in the private part of an instance of a generic unit.

13/5

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.

14/5

NOTE Pragmas Elaborate and Elaborate_All, which do not have associated aspects, are found in 10.2.1.

Wording Changes from Ada 2012

14.a/5

This subclause is new. These pragmas were moved here from 10.2.1.

J.15.15 Distribution Pragmas

1/5

This subclause defines pragmas that specify properties of units for distributed systems.

1.a/5

discussion

These pragmas are presented in the order that the aspects are defined in Annex E.

Syntax

2/5

The following pragmas are defined with the given forms:

3/5

pragma Shared_Passive[(library_unit_name)];

4/5

pragma Remote_Types[(library_unit_name)];

5/5

pragma Remote_Call_Interface[(library_unit_name)];

6/5

pragma All_Calls_Remote[(library_unit_name)];

7/5

Each of these pragmas is a library unit pragma.

Static Semantics

8/5

A categorization pragma is a pragma that specifies a corresponding categorization aspect.

9/5

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.

10/5

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.

11/5

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.

12

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.

13

A pragma All_Calls_Remote specifies that the All_Calls_Remote aspect (see E.2.3) of the library unit is True.

Wording Changes from Ada 2012

13.a/5

This subclause is new. These pragmas were moved here from Annex E, “Distributed Systems”.