Checking the Elaboration Order (GNAT User’s Guide for Native Platforms)

### 9.3 Checking the Elaboration Order ¶

To avoid placing the entire elaboration-order burden on the programmer, Ada provides three lines of defense:

- ‘Static semantics’

  Static semantic rules restrict the possible choice of elaboration order. For instance, if unit Client ‘with’s unit Server, then the spec of Server is always elaborated prior to Client. The same principle applies to child units - the spec of a parent unit is always elaborated prior to the child unit.

- ‘Dynamic semantics’

  Dynamic checks are performed at run time to ensure that a target is elaborated prior to a scenario that invokes it, thus avoiding ABE problems. A failed run-time check raises exception `Program_Error`. The following restrictions apply:

  - ‘Restrictions on calls’

    An entry, operator, or subprogram can be called from elaboration code only when the corresponding body has been elaborated.

  - ‘Restrictions on instantiations’

    A generic unit can be instantiated by elaboration code only when the corresponding body has been elaborated.

  - ‘Restrictions on task activation’

    A task can be activated by elaboration code only when the body of the associated task type has been elaborated.

  The restrictions above can be summarized by the following rule:

  ‘If a target has a body, then this body must be elaborated prior to the scenario that invokes the target.’

- ‘Elaboration control’

  Ada provides pragmas for you to specify the desired elaboration order.