10.1.4 The Compilation Process
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.
{
AI12-0445-1}
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 necessary 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;
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.
{
AI05-0229-1}
Similarly, the implementation has to be able to compile a call to a subprogram
for which aspect 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}
{
AI05-0005-1}
The consistency 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}
{
AI05-0229-1}
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
for which aspect Inline is True, the implementation may also remove any
compilation unit containing a call to that subprogram.
Ramification: {
AI05-0005-1}
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. An 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.
{
AI05-0229-1}
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 aspect 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 document.
{
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.
NOTE 1 The rules of the language
are enforced across
compilation
and compilation unit boundaries, just as they are enforced within a single
compilation unit.
Ramification: {
AI05-0299-1}
Note that Clause
1 requires an implementation
to detect illegal compilation units at compile time.
NOTE 2 {
AI12-0442-1}
An implementation can support a concept of a
library,
which contains
library_items.
If multiple libraries are supported, the implementation can document
how a single environment is constructed when a compilation unit is submitted
to the compiler. Naming conflicts between different libraries can, for
example, be resolved by treating each library as the root of a hierarchy
of child library units.
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;”.
NOTE 3 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}
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.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
