10.1.4 The Compilation Process
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).
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
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
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
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.
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.
5 The rules of the language are enforced
across
compilation
and compilation unit boundaries, just as they are enforced within a single
compilation unit.
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.
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.