10.1.4 The Compilation Process
1
Each compilation
unit submitted to the compiler is compiled in the context of an
environment
declarative_part (or simply, an
environment),
which is a conceptual
declarative_part that
forms the outermost declarative region of the context of any
compilation.
At run time, an environment forms the
declarative_part
of the body of the environment task of a partition (see
10.2,
“
Program Execution”).
2
The
declarative_items
of the environment are
library_items appearing
in an order such that there are no forward semantic dependences. Each
included subunit occurs in place of the corresponding stub. The visibility
rules apply as if the environment were the outermost declarative region,
except that
with_clauses are needed to make
declarations of library units visible (see
10.1.2).
3/2
The mechanisms for creating an environment and for
adding and replacing compilation units within an environment are implementation
defined. The mechanisms for adding a compilation unit mentioned in a
limited_with_clause to an environment are
implementation defined.
Name Resolution Rules
4/1
If a
library_unit_body
that is a
subprogram_body is submitted to
the compiler, it is interpreted only as a completion if a
library_unit_declaration
with the same
defining_program_unit_name already
exists in the environment for a subprogram other than an instance of
a generic subprogram or for a generic subprogram (even if the profile
of the body is not type conformant with that of the declaration); otherwise
the
subprogram_body is interpreted as both
the declaration and body of a library subprogram.
Legality Rules
5
When a compilation unit is compiled, all compilation
units upon which it depends semantically shall already exist in the environment;
the set of these compilation units shall be
consistent
in the sense that the new compilation unit shall not semantically depend
(directly or indirectly) on two different versions of the same compilation
unit, nor on an earlier version of itself.
Implementation Permissions
6/2
The implementation may require that a compilation
unit be legal before it can be mentioned in a limited_with_clause
or it can be inserted into the environment.
7/2
When a compilation unit that declares or renames
a library unit is added to the environment, the implementation may remove
from the environment any preexisting library_item
or subunit with the same full expanded name.
When a compilation unit that is a subunit or the body of a library unit
is added to the environment, the implementation may remove from the environment
any preexisting version of the same compilation unit. When a compilation
unit that contains a body_stub is added to
the environment, the implementation may remove any preexisting library_item
or subunit with the same full expanded name
as the body_stub. When a given compilation
unit is removed from the environment, the implementation may also remove
any compilation unit that depends semantically upon the given one. If
the given compilation unit contains the body of a subprogram to which
a pragma Inline applies, the implementation
may also remove any compilation unit containing a call to that subprogram.
8
5 The rules of the language are enforced
across compilation and compilation unit boundaries,
just as they are enforced within a single compilation unit.
9
6
An implementation
may support a concept of a
library, which contains
library_items.
If multiple libraries are supported, the implementation has to define
how a single environment is constructed when a compilation unit is submitted
to the compiler. Naming conflicts between different libraries might be
resolved by treating each library as the root of a hierarchy of child
library units.
10
7 A compilation unit containing an instantiation
of a separately compiled generic unit does not semantically depend on
the body of the generic unit. Therefore, replacing the generic body in
the environment does not result in the removal of the compilation unit
containing the instantiation.