10.1.4 The Compilation Process
{environment}
{environment declarative_part}
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”).
Ramification: At compile time, there
is no particular construct that the declarative region is considered
to be nested within — the environment is the universe.
To be honest: The environment is really
just a portion of a
declarative_part,
since there might, for example, be bodies that do not yet exist.
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).
{
AI95-00217-06}
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.
Implementation defined: The mechanisms
for creating an environment and for adding and replacing compilation
units.
Implementation defined: The mechanisms
for adding a compilation unit mentioned in a
limited_with_clause
to an environment.
Ramification: The traditional model,
used by most Ada 83 implementations, is that one places a compilation
unit in the environment by compiling it. Other models are possible. For
example, an implementation might define the environment to be a directory;
that is, the compilation units in the environment are all the compilation
units in the source files contained in the directory. In this model,
the mechanism for replacing a compilation unit with a new one is simply
to edit the source file containing that compilation unit.
Name Resolution Rules
Ramification: The principle here is that
a
subprogram_body
should be interpreted as only a completion if and only if it “might”
be legal as the completion of some preexisting declaration, where “might”
is defined in a way that does not require overload resolution to determine.
Hence, if the preexisting declaration is a
subprogram_declaration
or
generic_subprogram_declaration,
we treat the new
subprogram_body
as its completion, because it “might” be legal. If it turns
out that the profiles don't fully conform, it's an error. In all other
cases (the preexisting declaration is a package or a generic package,
or an instance of a generic subprogram, or a renaming, or a “spec-less”
subprogram, or in the case where there is no preexisting thing), the
subprogram_body
declares a new subprogram.
See also AI83-00266/09.
Legality Rules
When a compilation unit is compiled, all compilation
units upon which it depends semantically shall already exist in the environment;
{consistency (among compilation units)}
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.
Discussion: For example, if package declarations
A and B both say “with X;”, and the user compiles
a compilation unit that says “with A, B;”, then the
A and B have to be talking about the same version of X.
Ramification: What it means to be a “different
version” is not specified by the language. In some implementations,
it means that the compilation unit has been recompiled. In others, it
means that the source of the compilation unit has been edited in some
significant way.
Note that an implementation cannot require the
existence of compilation units upon which the given one does not semantically
depend. For example, an implementation is required to be able to compile
a compilation unit that says "with A;" when A's body
does not exist. It has to be able to detect errors without looking at
A's body.
Similarly, the implementation has to be able
to compile a call to a subprogram for which a
pragma
Inline has been specified without seeing the body of that subprogram
— inlining would not be achieved in this case, but the call is
still legal.
{
AI95-00217-06}
The second rule applies to limited views as well as the full view of
a compilation unit. That means that an implementation needs a way to
enforce consistency of limited views, not just of full views.
Implementation Permissions
{
AI95-00217-06}
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.
{
AI95-00214-01}
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.
Ramification: The permissions given in
this paragraph correspond to the traditional model, where compilation
units enter the environment by being compiled into it, and the compiler
checks their legality at that time. A implementation model in which the
environment consists of all source files in a given directory might not
want to take advantage of these permissions. Compilation units would
not be checked for legality as soon as they enter the environment; legality
checking would happen later, when compilation units are compiled. In
this model, compilation units might never be automatically removed from
the environment; they would be removed when the user explicitly deletes
a source file.
Note that the rule is recursive: if the above
permission is used to remove a compilation unit containing an inlined
subprogram call, then compilation units that depend semantically upon
the removed one may also be removed, and so on.
Note that here we are talking about dependences
among existing compilation units in the environment; it doesn't matter
what
with_clauses
are attached to the new compilation unit that triggered all this.
An implementation may have other modes in which
compilation units in addition to the ones mentioned above are removed.
For example, an implementation might inline subprogram calls without
an explicit
pragma
Inline. If so, it either has to have a mode in which that optimization
is turned off, or it has to automatically regenerate code for the inlined
calls without requiring the user to resubmit them to the compiler.
Discussion: {
8652/0108}
{
AI95-00077-01}
{
AI95-00114-01}
In the standard mode, implementations may only remove units from the
environment for one of the reasons listed here, or in response to an
explicit user command to modify the environment. It is not intended that
the act of compiling a unit is one of the “mechanisms” for
removing units other than those specified by this International Standard.
{
AI95-00214-01}
These rules are intended to ensure that an implementation never need
keep more than one compilation unit with any full expanded name. In particular,
it is not necessary to be able to have a subunit and a child unit with
the same name in the environment at one time.
5 The rules of the language are enforced
across
compilation
and compilation unit boundaries, just as they are enforced within a single
compilation unit.
Ramification: Note that Section 1 requires
an implementation to detect illegal compilation units at compile time.
6
{library}
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.
{program library: See
library} Implementation Note: Alternatively, naming
conflicts could be resolved via some sort of hiding rule.
Discussion: For example, the implementation
might support a command to import library Y into library X. If a root
library unit called LU (that is, Standard.LU) exists in Y, then from
the point of view of library X, it could be called Y.LU. X might contain
library units that say, “with Y.LU;”.
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.
Implementation Note: Therefore, implementations
have to be prepared to automatically instantiate generic bodies at link-time,
as needed. This might imply a complete automatic recompilation, but it
is the intent of the language that generic bodies can be (re)instantiated
without forcing all of the compilation units that semantically depend
on the compilation unit containing the instantiation to be recompiled.
Extensions to Ada 83
{
AI95-00077-01}
{
AI95-00114-01}
{
extensions to Ada 83}
Ada 83 allowed implementations
to require that the body of a generic unit be available when the instantiation
is compiled; that permission is dropped in Ada 95. This isn't really
an extension (it doesn't allow Ada users to write anything that they
couldn't in Ada 83), but there isn't a more appropriate category, and
it does allow users more flexibility when developing programs.
Wording Changes from Ada 95
{
AI95-00214-01}
The permissions to remove a unit from the environment were clarified
to ensure that it is never necessary to keep multiple (sub)units with
the same full expanded name in the environment.
{
AI95-00217-06}
Units mentioned in a
limited_with_clause
were added to several rules; limited views have the same presence in
the environment as the corresponding full views.
Sponsored by Ada-Europe