CbC/CbC_gcc: gcc/ada/doc/gnat_ugn/elaboration_order_handling_in

comparison gcc/ada/doc/gnat_ugn/elaboration_order_handling_in_gnat.rst @ 145:1830386684a0

gcc-9.2.0

author	anatofuz
date	Thu, 13 Feb 2020 11:34:05 +0900
parents	84e7813d76e9
children

comparison

equal deleted inserted replaced

-:84e7813d76e9
+:1830386684a0
 * The environment task executes the Ada program (if available) for that
 partition.
 In addition to the Ada terminology, this appendix defines the following terms:
+* *Invocation*
+The act of calling a subprogram, instantiating a generic, or activating a
+task.
 * *Scenario*
-A construct that is elaborated or executed by elaboration code is referred to
+A construct that is elaborated or invoked by elaboration code is referred to
 as an *elaboration scenario* or simply a **scenario**. GNAT recognizes the
 following scenarios:
 - ``'Access`` of entries, operators, and subprograms
 end Client;
 In the example above, the call to ``Server.Func`` is an elaboration scenario
 because it appears at the library level of package ``Client``. Note that the
 declaration of package ``Nested`` is ignored according to the definition
-given above. As a result, the call to ``Server.Func`` will be executed when
+given above. As a result, the call to ``Server.Func`` will be invoked when
 the spec of unit ``Client`` is elaborated.
 * *Package body statements*
 A scenario appears within the statement sequence of a package body when it is
 Proc;
 end Client;
 In the example above, the call to ``Proc`` is an elaboration scenario because
 it appears within the statement sequence of package body ``Client``. As a
-result, the call to ``Proc`` will be executed when the body of ``Client`` is
+result, the call to ``Proc`` will be invoked when the body of ``Client`` is
 elaborated.
 .. _Elaboration_Order:
 Elaboration Order
 The sequence by which the elaboration code of all units within a partition is
 executed is referred to as **elaboration order**.
 Within a single unit, elaboration code is executed in sequential order.
 ::
 package body Client is
 Result : ... := Server.Func;
 procedure Proc is
 package Inst is new Server.Gen;
 begin
 Inst.Eval (Result);
 end Proc;
 begin
 Proc;
 end Client;
 In the example above, the elaboration order within package body ``Client`` is
 as follows:
 1. The object declaration of ``Result`` is elaborated.
 The elaboration order of all units within a partition depends on the following
 factors:
 * |withed| units
+* parent units
 * purity of units
 * preelaborability of units
-* presence of elaboration control pragmas
+* presence of elaboration-control pragmas
+* invocations performed in elaboration code
 A program may have several elaboration orders depending on its structure.
 ::
 package Server is
 function Func (Index : Integer) return Integer;
 end Server;
 ::
 package body Server is
 Results : array (1 .. 5) of Integer := (1, 2, 3, 4, 5);
 function Func (Index : Integer) return Integer is
 begin
 return Results (Index);
 end Func;
 end Server;
 ::
 with Server;
 package Client is
 Val : constant Integer := Server.Func (3);
 end Client;
 ::
 with Client;
 procedure Main is begin null; end Main;
 The following elaboration order exhibits a fundamental problem referred to as
 *access-before-elaboration* or simply **ABE**.
 ::
 spec of Server
 spec of Client
 body of Server
 body of Main
 The elaboration of ``Server``'s spec materializes function ``Func``, making it
 callable. The elaboration of ``Client``'s spec elaborates the declaration of
 ``Val``. This invokes function ``Server.Func``, however the body of
 ``Server.Func`` has not been elaborated yet because ``Server``'s body comes
 ``Program_Error``.
 The following elaboration order avoids the ABE problem and the program can be
 successfully elaborated.
 ::
 spec of Server
 body of Server
 spec of Client
 body of Main
 Ada states that a total elaboration order must exist, but it does not define
 what this order is. A compiler is thus tasked with choosing a suitable
 elaboration order which satisfies the dependencies imposed by |with| clauses,
-unit categorization, and elaboration control pragmas. Ideally an order which
+unit categorization, elaboration-control pragmas, and invocations performed in
-avoids ABE problems should be chosen, however a compiler may not always find
+elaboration code. Ideally an order that avoids ABE problems should be chosen,
-such an order due to complications with respect to control and data flow.
+however a compiler may not always find such an order due to complications with
+respect to control and data flow.
 .. _Checking_the_Elaboration_Order:
 Checking the Elaboration Order
 ==============================
-To avoid placing the entire elaboration order burden on the programmer, Ada
+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
 - 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 executes it, thus avoiding ABE problems.
+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*
 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
-execution of the scenario that invokes, instantiates, or activates the
+scenario that invokes the target.*
-target.*
 * *Elaboration control*
 Pragmas are provided for the programmer to specify the desired elaboration
 order.
 * *pragma Elaborate_Body*
 Pragma ``Elaborate_Body`` requires that the body of a unit is elaborated
 immediately after its spec. This restriction guarantees that no client
-scenario can execute a server target before the target body has been
+scenario can invoke a server target before the target body has been
 elaborated because the spec and body are effectively "glued" together.
 ::
 package Server is
 Note that there are several allowable suborders for the specs and bodies of
 ``Math`` and ``Computer``, but the point is that these specs and bodies will
 be elaborated prior to ``Client``.
 Removing pragma ``Elaborate_All`` could result in the following incorrect
-elaboration order
+elaboration order:
 ::
 spec of Math
 spec of Computer
 .. index:: Dynamic elaboration model
 * *Dynamic elaboration model*
-This is the most permissive of the three elaboration models. When the
+This is the most permissive of the three elaboration models and emulates the
-dynamic model is in effect, GNAT assumes that all code within all units in
+behavior specified by the Ada Reference Manual. When the dynamic model is in
-a partition is elaboration code. GNAT performs very few diagnostics and
+effect, GNAT makes the following assumptions:
-generates run-time checks to verify the elaboration order of a program. This
-behavior is identical to that specified by the Ada Reference Manual. The
+- All code within all units in a partition is considered to be elaboration
-dynamic model is enabled with compiler switch :switch:`-gnatE`.
+code.
+- Some of the invocations in elaboration code may not take place at run time
+due to conditional execution.
+GNAT performs extensive diagnostics on a unit-by-unit basis for all scenarios
+that invoke internal targets. In addition, GNAT generates run-time checks for
+all external targets and for all scenarios that may exhibit ABE problems.
+The elaboration order is obtained by honoring all |with| clauses, purity and
+preelaborability of units, and elaboration-control pragmas. The dynamic model
+attempts to take all invocations in elaboration code into account. If an
+invocation leads to a circularity, GNAT ignores the invocation based on the
+assumptions stated above. An order obtained using the dynamic model may fail
+an ABE check at run time when GNAT ignored an invocation.
+The dynamic model is enabled with compiler switch :switch:`-gnatE`.
 .. index:: Static elaboration model
 * *Static elaboration model*
 This is the middle ground of the three models. When the static model is in
-effect, GNAT performs extensive diagnostics on a unit-by-unit basis for all
+effect, GNAT makes the following assumptions:
-scenarios that elaborate or execute internal targets. GNAT also generates
-run-time checks for all external targets and for all scenarios that may
+- Only code at the library level and in package body statements within all
-exhibit ABE problems. Finally, GNAT installs implicit ``Elaborate`` and
+units in a partition is considered to be elaboration code.
-``Elaborate_All`` pragmas for server units based on the dependencies of
-client units. The static model is the default model in GNAT.
+- All invocations in elaboration will take place at run time, regardless of
+conditional execution.
+GNAT performs extensive diagnostics on a unit-by-unit basis for all scenarios
+that invoke internal targets. In addition, GNAT generates run-time checks for
+all external targets and for all scenarios that may exhibit ABE problems.
+The elaboration order is obtained by honoring all |with| clauses, purity and
+preelaborability of units, presence of elaboration-control pragmas, and all
+invocations in elaboration code. An order obtained using the static model is
+guaranteed to be ABE problem-free, excluding dispatching calls and
+access-to-subprogram types.
+The static model is the default model in GNAT.
 .. index:: SPARK elaboration model
 * *SPARK elaboration model*
 This is the most conservative of the three models and enforces the SPARK
 rules of elaboration as defined in the SPARK Reference Manual, section 7.7.
 The SPARK model is in effect only when a scenario and a target reside in a
-region subject to SPARK_Mode On, otherwise the dynamic or static model is in
+region subject to ``SPARK_Mode On``, otherwise the dynamic or static model
-effect.
+is in effect.
-.. index:: Legacy elaboration model
+The SPARK model is enabled with compiler switch :switch:`-gnatd.v`.
-* *Legacy elaboration model*
+.. index:: Legacy elaboration models
+* *Legacy elaboration models*
 In addition to the three elaboration models outlined above, GNAT provides the
-elaboration model of pre-18.x versions referred to as `legacy elaboration
+following legacy models:
-model`. The legacy elaboration model is enabled with compiler switch
-:switch:`-gnatH`.
+- `Legacy elaboration-checking model` available in pre-18.x versions of GNAT.
+This model is enabled with compiler switch :switch:`-gnatH`.
+- `Legacy elaboration-order model` available in pre-20.x versions of GNAT.
+This model is enabled with binder switch :switch:`-H`.
 .. index:: Relaxed elaboration mode
 The dynamic, legacy, and static models can be relaxed using compiler switch
 :switch:`-gnatJ`, making them more permissive. Note that in this mode, GNAT
 may not diagnose certain elaboration issues or install run-time checks.
-.. _Common_Elaboration_Model_Traits":
+.. _Mixing_Elaboration_Models:
-Common Elaboration-model Traits
+Mixing Elaboration Models
-===============================
+=========================
-All three GNAT models are able to detect elaboration problems related to
+It is possible to mix units compiled with a different elaboration model,
-dispatching calls and a particular kind of ABE referred to as *guaranteed ABE*.
+however the following rules must be observed:
-* *Dispatching calls*
+* A client unit compiled with the dynamic model can only |with| a server unit
+that meets at least one of the following criteria:
-GNAT installs run-time checks for each primitive subprogram of each tagged
-type defined in a partition on the assumption that a dispatching call
+- The server unit is compiled with the dynamic model.
-invoked at elaboration time will execute one of these primitives. As a
-result, a dispatching call that executes a primitive whose body has not
+- The server unit is a GNAT implementation unit from the ``Ada``, ``GNAT``,
-been elaborated yet will raise exception ``Program_Error`` at run time. The
+``Interfaces``, or ``System`` hierarchies.
-checks can be suppressed using pragma ``Suppress (Elaboration_Check)``.
+- The server unit has pragma ``Pure`` or ``Preelaborate``.
-* *Guaranteed ABE*
+- The client unit has an explicit ``Elaborate_All`` pragma for the server
-A guaranteed ABE arises when the body of a target is not elaborated early
+unit.
-enough, and causes all scenarios that directly execute the target to fail.
+These rules ensure that elaboration checks are not omitted. If the rules are
+violated, the binder emits a warning:
+::
+warning: "x.ads" has dynamic elaboration checks and with's
+warning:   "y.ads" which has static elaboration checks
+The warnings can be suppressed by binder switch :switch:`-ws`.
+.. _ABE_Diagnostics:
+ABE Diagnostics
+===============
+GNAT performs extensive diagnostics on a unit-by-unit basis for all scenarios
+that invoke internal targets, regardless of whether the dynamic, SPARK, or
+static model is in effect.
+Note that GNAT emits warnings rather than hard errors whenever it encounters an
+elaboration problem. This is because the elaboration model in effect may be too
+conservative, or a particular scenario may not be invoked due conditional
+execution. The warnings can be suppressed selectively with ``pragma Warnings
+(Off)`` or globally with compiler switch :switch:`-gnatwL`.
+A *guaranteed ABE* arises when the body of a target is not elaborated early
+enough, and causes *all* scenarios that directly invoke the target to fail.
 ::
 package body Guaranteed_ABE is
 function ABE return Integer;
 Val : constant Integer := ABE;
 function ABE return Integer is
 begin
 ...
 end ABE;
 end Guaranteed_ABE;
 In the example above, the elaboration of ``Guaranteed_ABE``'s body elaborates
-the declaration of ``Val``. This invokes function ``ABE``, however the body
+the declaration of ``Val``. This invokes function ``ABE``, however the body of
-of ``ABE`` has not been elaborated yet. GNAT emits similar diagnostics in all
+``ABE`` has not been elaborated yet. GNAT emits the following diagnostic:
-three models:
+::
-::
+4.    Val : constant Integer := ABE;
-1. package body Guaranteed_ABE is
+|
-2.    function ABE return Integer;
+>>> warning: cannot call "ABE" before body seen
+>>> warning: Program_Error will be raised at run time
+A *conditional ABE* arises when the body of a target is not elaborated early
+enough, and causes *some* scenarios that directly invoke the target to fail.
+::
+1. package body Conditional_ABE is
+2.    procedure Force_Body is null;
 3.
-4.    Val : constant Integer := ABE;
+4.    generic
-|
+5.       with function Func return Integer;
->>> warning: cannot call "ABE" before body seen
+6.    package Gen is
->>> warning: Program_Error will be raised at run time
+7.       Val : constant Integer := Func;
+8.    end Gen;
-5.
-6.    function ABE return Integer is
-7.    begin
-8.       ...
-9.    end ABE;
-10. end Guaranteed_ABE;
-Note that GNAT emits warnings rather than hard errors whenever it encounters an
-elaboration problem. This is because the elaboration model in effect may be too
-conservative, or a particular scenario may not be elaborated or executed due to
-data and control flow. The warnings can be suppressed selectively with ``pragma
-Warnigns (Off)`` or globally with compiler switch :switch:`-gnatwL`.
-.. _Dynamic_Elaboration_Model_in_GNAT:
-Dynamic Elaboration Model in GNAT
-=================================
-The dynamic model assumes that all code within all units in a partition is
-elaboration code. As a result, run-time checks are installed for each scenario
-regardless of whether the target is internal or external. The checks can be
-suppressed using pragma ``Suppress (Elaboration_Check)``. This behavior is
-identical to that specified by the Ada Reference Manual. The following example
-showcases run-time checks installed by GNAT to verify the elaboration state of
-package ``Dynamic_Model``.
-::
-with Server;
-package body Dynamic_Model is
-procedure API is
-begin
-...
-end API;
-<check that the body of Server.Gen is elaborated>
-package Inst is new Server.Gen;
-T : Server.Task_Type;
-begin
-<check that the body of Server.Task_Type is elaborated>
-<check that the body of Server.Proc is elaborated>
-Server.Proc;
-end Dynamic_Model;
-The checks verify that the body of a target has been successfully elaborated
-before a scenario activates, calls, or instantiates a target.
-Note that no scenario within package ``Dynamic_Model`` calls procedure ``API``.
-In fact, procedure ``API`` may not be invoked by elaboration code within the
-partition, however the dynamic model assumes that this can happen.
-The dynamic model emits very few diagnostics, but can make suggestions on
-missing ``Elaborate`` and ``Elaborate_All`` pragmas for library-level
-scenarios. This information is available when compiler switch :switch:`-gnatel`
-is in effect.
-::
-1. with Server;
-2. package body Dynamic_Model is
-3.    Val : constant Integer := Server.Func;
-|
->>> info: call to "Func" during elaboration
->>> info: missing pragma "Elaborate_All" for unit "Server"
-4. end Dynamic_Model;
-.. _Static_Elaboration_Model_in_GNAT:
-Static Elaboration Model in GNAT
-================================
-In contrast to the dynamic model, the static model is more precise in its
-analysis of elaboration code. The model makes a clear distinction between
-internal and external targets, and resorts to different diagnostics and
-run-time checks based on the nature of the target.
-* *Internal targets*
-The static model performs extensive diagnostics on scenarios which elaborate
-or execute internal targets. The warnings resulting from these diagnostics
-are enabled by default, but can be suppressed selectively with ``pragma
-Warnings (Off)`` or globally with compiler switch :switch:`-gnatwL`.
-::
-1. package body Static_Model is
-2.    generic
-3.       with function Func return Integer;
-4.    package Gen is
-5.       Val : constant Integer := Func;
-6.    end Gen;
-7.
-8.    function ABE return Integer;
 9.
-10.    function Cause_ABE return Boolean is
+10.    function ABE return Integer;
-11.       package Inst is new Gen (ABE);
+11.
+12.    function Cause_ABE return Boolean is
+13.       package Inst is new Gen (ABE);
+14.    begin
+15.       ...
+16.    end Cause_ABE;
+17.
+18.    Val : constant Boolean := Cause_ABE;
+19.
+20.    function ABE return Integer is
+21.    begin
+22.       ...
+23.    end ABE;
+24.
+25.    Safe : constant Boolean := Cause_ABE;
+26. end Conditional_ABE;
+In the example above, the elaboration of package body ``Conditional_ABE``
+elaborates the declaration of ``Val``. This invokes function ``Cause_ABE``,
+which instantiates generic unit ``Gen`` as ``Inst``. The elaboration of
+``Inst`` invokes function ``ABE``, however the body of ``ABE`` has not been
+elaborated yet. GNAT emits the following diagnostic:
+::
+13.       package Inst is new Gen (ABE);
 |
->>> warning: in instantiation at line 5
+>>> warning: in instantiation at line 7
 >>> warning: cannot call "ABE" before body seen
 >>> warning: Program_Error may be raised at run time
->>> warning:   body of unit "Static_Model" elaborated
+>>> warning:   body of unit "Conditional_ABE" elaborated
->>> warning:   function "Cause_ABE" called at line 16
+>>> warning:   function "Cause_ABE" called at line 18
->>> warning:   function "ABE" called at line 5, instance at line 11
+>>> warning:   function "ABE" called at line 7, instance at line 13
-12.    begin
+Note that the same ABE problem does not occur with the elaboration of
-13.       ...
+declaration ``Safe`` because the body of function ``ABE`` has already been
-14.    end Cause_ABE;
+elaborated at that point.
-15.
-16.    Val : constant Boolean := Cause_ABE;
+.. _SPARK_Diagnostics:
-17.
-18.    function ABE return Integer is
+SPARK Diagnostics
-19.    begin
+=================
-20.       ...
-21.    end ABE;
+GNAT enforces the SPARK rules of elaboration as defined in the SPARK Reference
-22. end Static_Model;
+Manual section 7.7 when compiler switch :switch:`-gnatd.v` is in effect. Note
+that GNAT emits hard errors whenever it encounters a violation of the SPARK
-The example above illustrates an ABE problem within package ``Static_Model``,
+rules.
-which is hidden by several layers of indirection. The elaboration of package
-body ``Static_Model`` elaborates the declaration of ``Val``. This invokes
+::
-function ``Cause_ABE``, which instantiates generic unit ``Gen`` as ``Inst``.
-The elaboration of ``Inst`` invokes function ``ABE``, however the body of
+1. with Server;
-``ABE`` has not been elaborated yet.
+2. package body SPARK_Diagnostics with SPARK_Mode is
+3.    Val : constant Integer := Server.Func;
-* *External targets*
+|
+>>> call to "Func" during elaboration in SPARK
-The static model installs run-time checks to verify the elaboration status
+>>> unit "SPARK_Diagnostics" requires pragma "Elaborate_All" for "Server"
-of server targets only when the scenario that elaborates or executes that
+>>>   body of unit "SPARK_Model" elaborated
-target is part of the elaboration code of the client unit. The checks can be
+>>>   function "Func" called at line 3
-suppressed using pragma ``Suppress (Elaboration_Check)``.
+4. end SPARK_Diagnostics;
-::
+.. _Elaboration_Circularities:
-with Server;
-package body Static_Model is
+Elaboration Circularities
-generic
+=========================
-with function Func return Integer;
-package Gen is
+An **elaboration circularity** occurs whenever the elaboration of a set of
-Val : constant Integer := Func;
+units enters a deadlocked state, where each unit is waiting for another unit
-end Gen;
+to be elaborated. This situation may be the result of improper use of |with|
+clauses, elaboration-control pragmas, or invocations in elaboration code.
-function Call_Func return Boolean is
-<check that the body of Server.Func is elaborated>
+The following example exhibits an elaboration circularity.
-package Inst is new Gen (Server.Func);
+::
+with B; pragma Elaborate (B);
+package A is
+end A;
+::
+package B is
+procedure Force_Body;
+end B;
+::
+with C;
+package body B is
+procedure Force_Body is null;
+Elab : constant Integer := C.Func;
+end B;
+::
+package C is
+function Func return Integer;
+end C;
+::
+with A;
+package body C is
+function Func return Integer is
 begin
 ...
-end Call_Func;
+end Func;
+end C;
-Val : constant Boolean := Call_Func;
-end Static_Model;
+The binder emits the following diagnostic:
-In the example above, the elaboration of package body ``Static_Model``
+::
-elaborates the declaration of ``Val``. This invokes function ``Call_Func``,
-which instantiates generic unit ``Gen`` as ``Inst``. The elaboration of
+error: Elaboration circularity detected
-``Inst`` invokes function ``Server.Func``. Since ``Server.Func`` is an
+info:
-external target, GNAT installs a run-time check to verify that its body has
+info:    Reason:
-been elaborated.
+info:
+info:      unit "a (spec)" depends on its own elaboration
-In addition to checks, the static model installs implicit ``Elaborate`` and
+info:
-``Elaborate_All`` pragmas to guarantee safe elaboration use of server units.
+info:    Circularity:
-This information is available when compiler switch :switch:`-gnatel` is in
+info:
-effect.
+info:      unit "a (spec)" has with clause and pragma Elaborate for unit "b (spec)"
+info:      unit "b (body)" is in the closure of pragma Elaborate
-::
+info:      unit "b (body)" invokes a construct of unit "c (body)" at elaboration time
+info:      unit "c (body)" has with clause for unit "a (spec)"
-1. with Server;
+info:
-2. package body Static_Model is
+info:    Suggestions:
-3.    generic
+info:
-4.       with function Func return Integer;
+info:      remove pragma Elaborate for unit "b (body)" in unit "a (spec)"
-5.    package Gen is
+info:      use the dynamic elaboration model (compiler switch -gnatE)
-6.       Val : constant Integer := Func;
-7.    end Gen;
+The diagnostic consist of the following sections:
-8.
-9.    function Call_Func return Boolean is
+* Reason
-10.       package Inst is new Gen (Server.Func);
-|
+This section provides a short explanation describing why the set of units
->>> info: instantiation of "Gen" during elaboration
+could not be ordered.
->>> info: in instantiation at line 6
->>> info: call to "Func" during elaboration
+* Circularity
->>> info: in instantiation at line 6
->>> info: implicit pragma "Elaborate_All" generated for unit "Server"
+This section enumerates the units comprising the deadlocked set, along with
->>> info:   body of unit "Static_Model" elaborated
+their interdependencies.
->>> info:   function "Call_Func" called at line 15
->>> info:   function "Func" called at line 6, instance at line 10
+* Suggestions
-11.    begin
+This section enumerates various tactics for eliminating the circularity.
-12.       ...
-13.    end Call_Func;
-14.
-15.    Val : constant Boolean := Call_Func;
-|
->>> info: call to "Call_Func" during elaboration
-16. end Static_Model;
-In the example above, the elaboration of package body ``Static_Model``
-elaborates the declaration of ``Val``. This invokes function ``Call_Func``,
-which instantiates generic unit ``Gen`` as ``Inst``. The elaboration of
-``Inst`` invokes function ``Server.Func``. Since ``Server.Func`` is an
-external target, GNAT installs an implicit ``Elaborate_All`` pragma for unit
-``Server``. The pragma guarantees that both the spec and body of ``Server``,
-along with any additional dependencies that ``Server`` may require, are
-elaborated prior to the body of ``Static_Model``.
-.. _SPARK_Elaboration_Model_in_GNAT:
-SPARK Elaboration Model in GNAT
-===============================
-The SPARK model is identical to the static model in its handling of internal
-targets. The SPARK model, however, requires explicit ``Elaborate`` or
-``Elaborate_All`` pragmas to be present in the program when a target is
-external, and compiler switch :switch:`-gnatd.v` is in effect.
-::
-1. with Server;
-2. package body SPARK_Model with SPARK_Mode is
-3.    Val : constant Integer := Server.Func;
-|
->>> call to "Func" during elaboration in SPARK
->>> unit "SPARK_Model" requires pragma "Elaborate_All" for "Server"
->>>   body of unit "SPARK_Model" elaborated
->>>   function "Func" called at line 3
-4. end SPARK_Model;
-Legacy Elaboration Model in GNAT
-================================
-The legacy elaboration model is provided for compatibility with code bases
-developed with pre-18.x versions of GNAT. It is similar in functionality to
-the dynamic and static models of post-18.x version of GNAT, but may differ
-in terms of diagnostics and run-time checks. The legacy elaboration model is
-enabled with compiler switch :switch:`-gnatH`.
-.. _Mixing_Elaboration_Models:
-Mixing Elaboration Models
-=========================
-It is possible to mix units compiled with a different elaboration model,
-however the following rules must be observed:
-* A client unit compiled with the dynamic model can only |with| a server unit
-that meets at least one of the following criteria:
-- The server unit is compiled with the dynamic model.
-- The server unit is a GNAT implementation unit from the Ada, GNAT,
-Interfaces, or System hierarchies.
-- The server unit has pragma ``Pure`` or ``Preelaborate``.
-- The client unit has an explicit ``Elaborate_All`` pragma for the server
-unit.
-These rules ensure that elaboration checks are not omitted. If the rules are
-violated, the binder emits a warning:
-::
-warning: "x.ads" has dynamic elaboration checks and with's
-warning:   "y.ads" which has static elaboration checks
-The warnings can be suppressed by binder switch :switch:`-ws`.
-.. _Elaboration_Circularities:
-Elaboration Circularities
-=========================
-If the binder cannot find an acceptable elaboration order, it outputs detailed
-diagnostics describing an **elaboration circularity**.
-::
-package Server is
-function Func return Integer;
-end Server;
-::
-with Client;
-package body Server is
-function Func return Integer is
-begin
-...
-end Func;
-end Server;
-::
-with Server;
-package Client is
-Val : constant Integer := Server.Func;
-end Client;
-::
-with Client;
-procedure Main is begin null; end Main;
-::
-error: elaboration circularity detected
-info:    "server (body)" must be elaborated before "client (spec)"
-info:       reason: implicit Elaborate_All in unit "client (spec)"
-info:       recompile "client (spec)" with -gnatel for full details
-info:          "server (body)"
-info:             must be elaborated along with its spec:
-info:          "server (spec)"
-info:             which is withed by:
-info:          "client (spec)"
-info:    "client (spec)" must be elaborated before "server (body)"
-info:       reason: with clause
-In the example above, ``Client`` must be elaborated prior to ``Main`` by virtue
-of a |with| clause. The elaboration of ``Client`` invokes ``Server.Func``, and
-static model generates an implicit ``Elaborate_All`` pragma for ``Server``. The
-pragma implies that both the spec and body of ``Server``, along with any units
-they |with|, must be elaborated prior to ``Client``. However, ``Server``'s body
-|withs| ``Client``, implying that ``Client`` must be elaborated prior to
-``Server``. The end result is that ``Client`` must be elaborated prior to
-``Client``, and this leads to a circularity.
 .. _Resolving_Elaboration_Circularities:
 Resolving Elaboration Circularities
 ===================================
-When faced with an elaboration circularity, a programmer has several options
+The most desirable option from the point of view of long-term maintenance is to
-available.
+rearrange the program so that the elaboration problems are avoided. One useful
+technique is to place the elaboration code into separate child packages.
-* *Fix the program*
+Another is to move some of the initialization code to explicitly invoked
+subprograms, where the program controls the order of initialization explicitly.
-The most desirable option from the point of view of long-term maintenance
+Although this is the most desirable option, it may be impractical and involve
-is to rearrange the program so that the elaboration problems are avoided.
+too much modification, especially in the case of complex legacy code.
-One useful technique is to place the elaboration code into separate child
-packages. Another is to move some of the initialization code to explicitly
+When faced with an elaboration circularity, the programmer should also consider
-invoked subprograms, where the program controls the order of initialization
+the tactics given in the suggestions section of the circularity diagnostic.
-explicitly. Although this is the most desirable option, it may be impractical
+Depending on the units involved in the circularity, their |with| clauses,
-and involve too much modification, especially in the case of complex legacy
+purity, preelaborability, presence of elaboration-control pragmas and
-code.
+invocations at elaboration time, the binder may suggest one or more of the
+following tactics to eliminate the circularity:
-* *Switch to more permissive elaboration model*
+* Pragma Elaborate elimination
-If the compilation was performed using the static model, enable the dynamic
-model with compiler switch :switch:`-gnatE`. GNAT will no longer generate
+::
-implicit ``Elaborate`` and ``Elaborate_All`` pragmas, resulting in a behavior
-identical to that specified by the Ada Reference Manual. The binder will
+remove pragma Elaborate for unit "..." in unit "..."
-generate an executable program that may or may not raise ``Program_Error``,
-and it is the programmer's responsibility to ensure that it does not raise
+This tactic is suggested when the binder has determined that pragma
-``Program_Error``.
+``Elaborate``:
-If the compilation was performed using a post-18.x version of GNAT, consider
+- Prevents a set of units from being elaborated.
-using the legacy elaboration model, in the following order:
+- The removal of the pragma will not eliminate the semantic effects of the
-- Use the legacy static elaboration model, with compiler switch
+pragma. In other words, the argument of the pragma will still be elaborated
-:switch:`-gnatH`.
+prior to the unit containing the pragma.
-- Use the legacy dynamic elaboration model, with compiler switches
+- The removal of the pragma will enable the successful ordering of the units.
-:switch:`-gnatH` :switch:`-gnatE`.
+The programmer should remove the pragma as advised, and rebuild the program.
-- Use the relaxed legacy static elaboration model, with compiler switches
-:switch:`-gnatH` :switch:`-gnatJ`.
+* Pragma Elaborate_All elimination
-- Use the relaxed legacy dynamic elaboration model, with compiler switches
+::
-:switch:`-gnatH` :switch:`-gnatJ` :switch:`-gnatE`.
+remove pragma Elaborate_All for unit "..." in unit "..."
-* *Suppress all elaboration checks*
+This tactic is suggested when the binder has determined that pragma
-The drawback of run-time checks is that they generate overhead at run time,
+``Elaborate_All``:
-both in space and time. If the programmer is absolutely sure that a program
-will not raise an elaboration-related ``Program_Error``, then using the
+- Prevents a set of units from being elaborated.
-pragma ``Suppress (Elaboration_Check)`` globally (as a configuration pragma)
-will eliminate all run-time checks.
+- The removal of the pragma will not eliminate the semantic effects of the
+pragma. In other words, the argument of the pragma along with its |with|
-* *Suppress elaboration checks selectively*
+closure will still be elaborated prior to the unit containing the pragma.
-If a scenario cannot possibly lead to an elaboration ``Program_Error``,
+- The removal of the pragma will enable the successful ordering of the units.
-and the binder nevertheless complains about implicit ``Elaborate`` and
-``Elaborate_All`` pragmas that lead to elaboration circularities, it
+The programmer should remove the pragma as advised, and rebuild the program.
-is possible to suppress the generation of implicit ``Elaborate`` and
-``Elaborate_All`` pragmas, as well as run-time checks. Clearly this can
+* Pragma Elaborate_All downgrade
-be unsafe, and it is the responsibility of the programmer to make sure
-that the resulting program has no elaboration anomalies. Pragma
+::
-``Suppress (Elaboration_Check)`` can be used with different levels of
-granularity to achieve these effects.
+change pragma Elaborate_All for unit "..." to Elaborate in unit "..."
-- *Target suppression*
+This tactic is always suggested with the pragma ``Elaborate_All`` elimination
+tactic. It offers a different alernative of guaranteeing that the argument of
-When the pragma is placed in a declarative part, without a second argument
+the pragma will still be elaborated prior to the unit containing the pragma.
-naming an entity, it will suppress implicit ``Elaborate`` and
-``Elaborate_All`` pragma generation, as well as run-time checks, on all
+The programmer should update the pragma as advised, and rebuild the program.
-targets within the region.
+* Pragma Elaborate_Body elimination
-::
+::
-package Range_Suppress is
-pragma Suppress (Elaboration_Check);
+remove pragma Elaborate_Body in unit "..."
-function Func return Integer;
+This tactic is suggested when the binder has determined that pragma
+``Elaborate_Body``:
-generic
-procedure Gen;
+- Prevents a set of units from being elaborated.
-pragma Unsuppress (Elaboration_Check);
+- The removal of the pragma will enable the successful ordering of the units.
-task type Tsk;
+Note that the binder cannot determine whether the pragma is required for
-end Range_Suppress;
+other purposes, such as guaranteeing the initialization of a variable
+declared in the spec by elaboration code in the body.
-In the example above, a pair of Suppress/Unsuppress pragmas define a region
-of suppression within package ``Range_Suppress``. As a result, no implicit
+The programmer should remove the pragma as advised, and rebuild the program.
-``Elaborate`` and ``Elaborate_All`` pragmas, nor any run-time checks, will
-be generated by callers of ``Func`` and instantiators of ``Gen``. Note that
+* Use of pragma Restrictions
-task type ``Tsk`` is not within this region.
+::
-An alternative to the region-based suppression is to use multiple
-``Suppress`` pragmas with arguments naming specific entities for which
+use pragma Restrictions (No_Entry_Calls_In_Elaboration_Code)
-elaboration checks should be suppressed:
+This tactic is suggested when the binder has determined that a task
-::
+activation at elaboration time:
-package Range_Suppress is
+- Prevents a set of units from being elaborated.
-function Func return Integer;
-pragma Suppress (Elaboration_Check, Func);
+Note that the binder cannot determine with certainty whether the task will
+block at elaboration time.
-generic
-procedure Gen;
+The programmer should create a configuration file, place the pragma within,
-pragma Suppress (Elaboration_Check, Gen);
+update the general compilation arguments, and rebuild the program.
-task type Tsk;
+* Use of dynamic elaboration model
-end Range_Suppress;
+::
-- *Scenario suppression*
+use the dynamic elaboration model (compiler switch -gnatE)
-When the pragma ``Suppress`` is placed in a declarative or statement
-part, without an entity argument, it will suppress implicit ``Elaborate``
+This tactic is suggested when the binder has determined that an invocation at
-and ``Elaborate_All`` pragma generation, as well as run-time checks, on
+elaboration time:
-all scenarios within the region.
+- Prevents a set of units from being elaborated.
-::
+- The use of the dynamic model will enable the successful ordering of the
-with Server;
+units.
-package body Range_Suppress is
-pragma Suppress (Elaboration_Check);
+The programmer has two options:
-function Func return Integer is
+- Determine the units involved in the invocation using the detailed
-begin
+invocation information, and add compiler switch :switch:`-gnatE` to the
-return Server.Func;
+compilation arguments of selected files only. This approach will yield
-end Func;
+safer elaboration orders compared to the other option because it will
+minimize the opportunities presented to the dynamic model for ignoring
-procedure Gen is
+invocations.
-begin
-Server.Proc;
+- Add compiler switch :switch:`-gnatE` to the general compilation arguments.
-end Gen;
+* Use of detailed invocation information
-pragma Unsuppress (Elaboration_Check);
+::
-task body Tsk is
-begin
+use detailed invocation information (compiler switch -gnatd_F)
-Server.Proc;
-end Tsk;
+This tactic is always suggested with the use of the dynamic model tactic. It
-end Range_Suppress;
+causes the circularity section of the circularity diagnostic to describe the
+flow of elaboration code from a unit to a unit, enumerating all such paths in
-In the example above, a pair of Suppress/Unsuppress pragmas define a region
+the process.
-of suppression within package body ``Range_Suppress``. As a result, the
-calls to ``Server.Func`` in ``Func`` and ``Server.Proc`` in ``Gen`` will
+The programmer should analyze this information to determine which units
-not generate any implicit ``Elaborate`` and ``Elaborate_All`` pragmas or
+should be compiled with the dynamic model.
-run-time checks.
+* Forced-dependency elimination
-.. _Resolving_Task_Issues:
+::
-Resolving Task Issues
-=====================
+remove the dependency of unit "..." on unit "..." from the argument of switch -f
-The model of execution in Ada dictates that elaboration must first take place,
+This tactic is suggested when the binder has determined that a dependency
-and only then can the main program be started. Tasks which are activated during
+present in the forced-elaboration-order file indicated by binder switch
-elaboration violate this model and may lead to serious concurrent problems at
+:switch:`-f`:
-elaboration time.
+- Prevents a set of units from being elaborated.
-A task can be activated in two different ways:
+- The removal of the dependency will enable the successful ordering of the
-* The task is created by an allocator in which case it is activated immediately
+units.
-after the allocator is evaluated.
+The programmer should edit the forced-elaboration-order file, remove the
-* The task is declared at the library level or within some nested master in
+dependency, and rebind the program.
-which case it is activated before starting execution of the statement
-sequence of the master defining the task.
+* All forced-dependency elimination
-Since the elaboration of a partition is performed by the environment task
+::
-servicing that partition, any tasks activated during elaboration may be in
-a race with the environment task, and lead to unpredictable state and behavior.
+remove switch -f
-The static model seeks to avoid such interactions by assuming that all code in
-the task body is executed at elaboration time, if the task was activated by
+This tactic is suggested in case editing the forced-elaboration-order file is
-elaboration code.
+not an option.
-::
+The programmer should remove binder switch :switch:`-f` from the binder
+arguments, and rebind.
-package Decls is
-task Lib_Task is
+* Multiple-circularities diagnostic
-entry Start;
-end Lib_Task;
+::
-type My_Int is new Integer;
+diagnose all circularities (binder switch -d_C)
-function Ident (M : My_Int) return My_Int;
+By default, the binder will diagnose only the highest-precedence circularity.
-end Decls;
+If the program contains multiple circularities, the binder will suggest the
+use of binder switch :switch:`-d_C` in order to obtain the diagnostics of all
-::
+circularities.
-with Utils;
+The programmer should add binder switch :switch:`-d_C` to the binder
-package body Decls is
+arguments, and rebind.
-task body Lib_Task is
-begin
+If none of the tactics suggested by the binder eliminate the elaboration
-accept Start;
+circularity, the programmer should consider using one of the legacy elaboration
-Utils.Put_Val (2);
+models, in the following order:
-end Lib_Task;
+* Use the pre-20.x legacy elaboration-order model, with binder switch
-function Ident (M : My_Int) return My_Int is
+:switch:`-H`.
-begin
-return M;
+* Use both pre-18.x and pre-20.x legacy elaboration models, with compiler
-end Ident;
+switch :switch:`-gnatH` and binder switch :switch:`-H`.
-end Decls;
+* Use the relaxed static-elaboration model, with compiler switches
-::
+:switch:`-gnatH` :switch:`-gnatJ` and binder switch :switch:`-H`.
-with Decls;
+* Use the relaxed dynamic-elaboration model, with compiler switches
-package Utils is
+:switch:`-gnatH` :switch:`-gnatJ` :switch:`-gnatE` and binder switch
-procedure Put_Val (Arg : Decls.My_Int);
+:switch:`-H`.
-end Utils;
-::
-with Ada.Text_IO; use Ada.Text_IO;
-package body Utils is
-procedure Put_Val (Arg : Decls.My_Int) is
-begin
-Put_Line (Arg'Img);
-end Put_Val;
-end Utils;
-::
-with Decls;
-procedure Main is
-begin
-Decls.Lib_Task.Start;
-end Main;
-When the above example is compiled with the static model, an elaboration
-circularity arises:
-::
-error: elaboration circularity detected
-info:    "decls (body)" must be elaborated before "decls (body)"
-info:       reason: implicit Elaborate_All in unit "decls (body)"
-info:       recompile "decls (body)" with -gnatel for full details
-info:          "decls (body)"
-info:             must be elaborated along with its spec:
-info:          "decls (spec)"
-info:             which is withed by:
-info:          "utils (spec)"
-info:             which is withed by:
-info:          "decls (body)"
-In the above example, ``Decls`` must be elaborated prior to ``Main`` by virtue
-of a with clause. The elaboration of ``Decls`` activates task ``Lib_Task``. The
-static model conservatibely assumes that all code within the body of
-``Lib_Task`` is executed, and generates an implicit ``Elaborate_All`` pragma
-for ``Units`` due to the call to ``Utils.Put_Val``. The pragma implies that
-both the spec and body of ``Utils``, along with any units they |with|,
-must be elaborated prior to ``Decls``. However, ``Utils``'s spec |withs|
-``Decls``, implying that ``Decls`` must be elaborated before ``Utils``. The end
-result is that ``Utils`` must be elaborated prior to ``Utils``, and this
-leads to a circularity.
-In reality, the example above will not exhibit an ABE problem at run time.
-When the body of task ``Lib_Task`` is activated, execution will wait for entry
-``Start`` to be accepted, and the call to ``Utils.Put_Val`` will not take place
-at elaboration time. Task ``Lib_Task`` will resume its execution after the main
-program is executed because ``Main`` performs a rendezvous with
-``Lib_Task.Start``, and at that point all units have already been elaborated.
-As a result, the static model may seem overly conservative, partly because it
-does not take control and data flow into account.
-When faced with a task elaboration circularity, a programmer has several
-options available:
-* *Use the dynamic model*
-The dynamic model does not generate implicit ``Elaborate`` and
-``Elaborate_All`` pragmas. Instead, it will install checks prior to every
-call in the example above, thus verifying the successful elaboration of
-``Utils.Put_Val`` in case the call to it takes place at elaboration time.
-The dynamic model is enabled with compiler switch :switch:`-gnatE`.
-* *Isolate the tasks*
-Relocating tasks in their own separate package could decouple them from
-dependencies that would otherwise cause an elaboration circularity. The
-example above can be rewritten as follows:
-::
-package Decls1 is                --  new
-task Lib_Task is
-entry Start;
-end Lib_Task;
-end Decls1;
-::
-with Utils;
-package body Decls1 is           --  new
-task body Lib_Task is
-begin
-accept Start;
-Utils.Put_Val (2);
-end Lib_Task;
-end Decls1;
-::
-package Decls2 is                --  new
-type My_Int is new Integer;
-function Ident (M : My_Int) return My_Int;
-end Decls2;
-::
-with Utils;
-package body Decls2 is           --  new
-function Ident (M : My_Int) return My_Int is
-begin
-return M;
-end Ident;
-end Decls2;
-::
-with Decls2;
-package Utils is
-procedure Put_Val (Arg : Decls2.My_Int);
-end Utils;
-::
-with Ada.Text_IO; use Ada.Text_IO;
-package body Utils is
-procedure Put_Val (Arg : Decls2.My_Int) is
-begin
-Put_Line (Arg'Img);
-end Put_Val;
-end Utils;
-::
-with Decls1;
-procedure Main is
-begin
-Decls1.Lib_Task.Start;
-end Main;
-* *Declare the tasks*
-The original example uses a single task declaration for ``Lib_Task``. An
-explicit task type declaration and a properly placed task object could avoid
-the dependencies that would otherwise cause an elaboration circularity. The
-example can be rewritten as follows:
-::
-package Decls is
-task type Lib_Task is         --  new
-entry Start;
-end Lib_Task;
-type My_Int is new Integer;
-function Ident (M : My_Int) return My_Int;
-end Decls;
-::
-with Utils;
-package body Decls is
-task body Lib_Task is
-begin
-accept Start;
-Utils.Put_Val (2);
-end Lib_Task;
-function Ident (M : My_Int) return My_Int is
-begin
-return M;
-end Ident;
-end Decls;
-::
-with Decls;
-package Utils is
-procedure Put_Val (Arg : Decls.My_Int);
-end Utils;
-::
-with Ada.Text_IO; use Ada.Text_IO;
-package body Utils is
-procedure Put_Val (Arg : Decls.My_Int) is
-begin
-Put_Line (Arg'Img);
-end Put_Val;
-end Utils;
-::
-with Decls;
-package Obj_Decls is             --  new
-Task_Obj : Decls.Lib_Task;
-end Obj_Decls;
-::
-with Obj_Decls;
-procedure Main is
-begin
-Obj_Decls.Task_Obj.Start;     --  new
-end Main;
-* *Use restriction No_Entry_Calls_In_Elaboration_Code*
-The issue exhibited in the original example under this section revolves
-around the body of ``Lib_Task`` blocking on an accept statement. There is
-no rule to prevent elaboration code from performing entry calls, however in
-practice this is highly unusual. In addition, the pattern of starting tasks
-at elaboration time and then immediately blocking on accept or select
-statements is quite common.
-If a programmer knows that elaboration code will not perform any entry
-calls, then the programmer can indicate that the static model should not
-process the remainder of a task body once an accept or select statement has
-been encountered. This behavior can be specified by a configuration pragma:
-::
-pragma Restrictions (No_Entry_Calls_In_Elaboration_Code);
-In addition to the change in behavior with respect to task bodies, the
-static model will verify that no entry calls take place at elaboration time.
 .. _Elaboration_Related_Compiler_Switches:
 Elaboration-related Compiler Switches
 =====================================
 .. index:: -gnatE  (gnat)
 :switch:`-gnatE`
 Dynamic elaboration checking mode enabled
-When this switch is in effect, GNAT activates the dynamic elaboration model.
+When this switch is in effect, GNAT activates the dynamic model.
 .. index:: -gnatel  (gnat)
 :switch:`-gnatel`
 Turn on info messages on generated Elaborate[_All] pragmas
+This switch is only applicable to the pre-20.x legacy elaboration models.
+The post-20.x elaboration model no longer relies on implicitly generated
+``Elaborate`` and ``Elaborate_All`` pragmas to order units.
 When this switch is in effect, GNAT will emit the following supplementary
 information depending on the elaboration model in effect.
 - *Dynamic model*
 GNAT will indicate missing ``Elaborate`` and ``Elaborate_All`` pragmas for
 all library-level scenarios within the partition.
 - *Static model*
-GNAT will indicate all scenarios executed during elaboration. In addition,
+GNAT will indicate all scenarios invoked during elaboration. In addition,
 it will provide detailed traceback when an implicit ``Elaborate`` or
 ``Elaborate_All`` pragma is generated.
 - *SPARK model*
 model to output trace information of elaboration issues. The trace
 information could shed light on previously unforeseen dependencies, as well
 as their origins. Elaboration warnings are enabled with compiler switch
 :switch:`-gnatwl`.
-* Use switch :switch:`-gnatel` to obtain messages on generated implicit
+* Cosider the tactics given in the suggestions section of the circularity
-``Elaborate`` and ``Elaborate_All`` pragmas. The trace information could
+diagnostic.
-indicate why a server unit must be elaborated prior to a client unit.
-* If the warnings produced by the static model indicate that a task is
-involved, consider the options in section `Resolving Task Issues`_.
 * If none of the steps outlined above resolve the circularity, use a more
 permissive elaboration model, in the following order:
-- Use the dynamic elaboration model, with compiler switch :switch:`-gnatE`.
+- Use the pre-20.x legacy elaboration-order model, with binder switch
+:switch:`-H`.
-- Use the legacy static elaboration model, with compiler switch
-:switch:`-gnatH`.
+- Use both pre-18.x and pre-20.x legacy elaboration models, with compiler
+switch :switch:`-gnatH` and binder switch :switch:`-H`.
-- Use the legacy dynamic elaboration model, with compiler switches
-:switch:`-gnatH` :switch:`-gnatE`.
+- Use the relaxed static elaboration model, with compiler switches
+:switch:`-gnatH` :switch:`-gnatJ` and binder switch :switch:`-H`.
-- Use the relaxed legacy static elaboration model, with compiler switches
-:switch:`-gnatH` :switch:`-gnatJ`.
+- Use the relaxed dynamic elaboration model, with compiler switches
+:switch:`-gnatH` :switch:`-gnatJ` :switch:`-gnatE` and binder switch
-- Use the relaxed legacy dynamic elaboration model, with compiler switches
+:switch:`-H`.
-:switch:`-gnatH` :switch:`-gnatJ` :switch:`-gnatE`.
 .. _Inspecting_the_Chosen_Elaboration_Order:
 Inspecting the Chosen Elaboration Order
 =======================================
 `b~xxx.adb`. On certain targets, this file appears as `b_xxx.adb`. The
 elaboration order appears as a sequence of calls to ``Elab_Body`` and
 ``Elab_Spec``, interspersed with assignments to `Exxx` which indicates that a
 particular unit is elaborated. For example:
 ::
 System.Soft_Links'Elab_Body;
 E14 := True;
 System.Secondary_Stack'Elab_Body;
 E18 := True;
 System.Exception_Table'Elab_Body;
 E24 := True;
 Ada.Io_Exceptions'Elab_Spec;
 E67 := True;
 Ada.Tags'Elab_Spec;
 Ada.Streams'Elab_Spec;
 E43 := True;
 Interfaces.C'Elab_Spec;
 E69 := True;
 System.Finalization_Root'Elab_Spec;
 E60 := True;
 System.Os_Lib'Elab_Body;
 E71 := True;
 System.Finalization_Implementation'Elab_Spec;
 System.Finalization_Implementation'Elab_Body;
 E62 := True;
 Ada.Finalization'Elab_Spec;
 E58 := True;
 Ada.Finalization.List_Controller'Elab_Spec;
 E76 := True;
 System.File_Control_Block'Elab_Spec;
 E74 := True;
 System.File_Io'Elab_Body;
 E56 := True;
 Ada.Tags'Elab_Body;
 E45 := True;
 Ada.Text_Io'Elab_Spec;
 Ada.Text_Io'Elab_Body;
 E07 := True;
 Note also binder switch :switch:`-l`, which outputs the chosen elaboration
 order and provides a more readable form of the above:
 ::
 ada (spec)
 interfaces (spec)
 system (spec)
 system.case_util (spec)
 system.case_util (body)
 system.concat_2 (spec)
 system.concat_2 (body)
 system.concat_3 (spec)
 system.concat_3 (body)
 system.htable (spec)
 system.parameters (spec)
 system.parameters (body)
 system.crtl (spec)
 interfaces.c_streams (spec)
 interfaces.c_streams (body)
 system.restrictions (spec)
 system.restrictions (body)
 system.standard_library (spec)
 system.exceptions (spec)
 system.exceptions (body)
 system.storage_elements (spec)
 system.storage_elements (body)
 system.secondary_stack (spec)
 system.stack_checking (spec)
 system.stack_checking (body)
 system.string_hash (spec)
 system.string_hash (body)
 system.htable (body)
 system.strings (spec)
 system.strings (body)
 system.traceback (spec)
 system.traceback (body)
 system.traceback_entries (spec)
 system.traceback_entries (body)
 ada.exceptions (spec)
 ada.exceptions.last_chance_handler (spec)
 system.soft_links (spec)
 system.soft_links (body)
 ada.exceptions.last_chance_handler (body)
 system.secondary_stack (body)
 system.exception_table (spec)
 system.exception_table (body)
 ada.io_exceptions (spec)
 ada.tags (spec)
 ada.streams (spec)
 interfaces.c (spec)
 interfaces.c (body)
 system.finalization_root (spec)
 system.finalization_root (body)
 system.memory (spec)
 system.memory (body)
 system.standard_library (body)
 system.os_lib (spec)
 system.os_lib (body)
 system.unsigned_types (spec)
 system.stream_attributes (spec)
 system.stream_attributes (body)
 system.finalization_implementation (spec)
 system.finalization_implementation (body)
 ada.finalization (spec)
 ada.finalization (body)
 ada.finalization.list_controller (spec)
 ada.finalization.list_controller (body)
 system.file_control_block (spec)
 system.file_io (spec)
 system.file_io (body)
 system.val_uns (spec)
 system.val_util (spec)
 system.val_util (body)
 system.val_uns (body)
 system.wch_con (spec)
 system.wch_con (body)
 system.wch_cnv (spec)
 system.wch_jis (spec)
 system.wch_jis (body)
 system.wch_cnv (body)
 system.wch_stw (spec)
 system.wch_stw (body)
 ada.tags (body)
 ada.exceptions (body)
 ada.text_io (spec)
 ada.text_io (body)
 text_io (spec)
 gdbstr (body)

Mercurial > hg > CbC > CbC_gcc

comparison gcc/ada/doc/gnat_ugn/elaboration_order_handling_in_gnat.rst @ 145:1830386684a0