Contents   Index   Previous   Next

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
   The mechanisms for creating an environment and for adding and replacing compilation units within an environment are implementation defined.
3.a
Implementation defined: The mechanisms for creating an environment and for adding and replacing compilation units.
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} 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.

Implementation Permissions

6
   The implementation may require that a compilation unit be legal before inserting it into the environment.
7
   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 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 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/1
Discussion: {8652/0108} 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 ``mechansisms'' for removing units other than those specified by this International Standard.
NOTES
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.

Contents   Index   Previous   Next   Legal