10.1.4 The Compilation Process
1
{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”).
1.a
Ramification: At compile time, there
is no particular construct that the declarative region is considered
to be nested within — the environment is the universe.
1.b
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.
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
{
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. 3.a
Implementation defined: The mechanisms
for creating an environment and for adding and replacing compilation
units.
3.a.1/2
Implementation defined:
The mechanisms for adding a compilation
unit mentioned in a limited_with_clause to
an environment.
3.b
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
4/1
{
8652/0032}
{
AI95-00192-01}
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 for
a subprogram or a generic subprogram 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.
{type conformance [partial]}
4.a
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.
4.b
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.
4.c
See also AI83-00266/09.
Legality Rules
5
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.
5.a
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.
5.b
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.
5.c
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.
5.d
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.
5.e/2
{
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
6/2
{
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 inserting it
into the environment.
7/2
{
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 with
the same defining_program_unit_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.
7.a
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.
7.b
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.
7.c
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.
7.d
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.
7.d.1/2
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 mechansisms ”
for removing units other than those specified by this International Standard.
7.e/2
{
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.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.
8.a
Ramification: Note that Section 1 requires
an implementation to detect illegal compilation units at compile time.
9
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}
9.a
Implementation Note: Alternatively, naming
conflicts could be resolved via some sort of hiding rule.
9.b
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;”.
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.
10.a
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
10.b/2
{
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
10.c/2
{
8652/0032}
{
AI95-00192-01}
Corrigendum: The wording was clarified to
ensure that a subprogram_body is not considered
a completion of an instance of a generic subprogram.10.d/2
{
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.10.e/2
{
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