10.1.6 Environment-Level Visibility Rules
[The normal visibility rules do not apply within
or a context_clause
nor within a pragma
that appears at the place of a compilation unit. The special visibility
rules for those contexts are given here.]
at the beginning of an explicit a
and within a nonlimited_with_clause with_clause
the only declarations that are visible are those that are explicit library_item
of the environment, and the only declarations that are directly visible
are those that are explicit
of the environment. Within a limited_with_clause,
the only declarations that are visible are those that are the implicit
declaration of the limited view of a library package of the environment,
and the only declarations that are directly visible are those that are
the implicit declaration of the limited view of a root library package.
Notwithstanding the rules of 4.1.3, an expanded
name in a with_clause
may consist of a prefix
that denotes a generic package and a selector_name
that denotes a child of that generic package. [(The child is necessarily
a generic unit; see 10.1.1.)]
Ramification: In “package
P.Q.R is ... end P.Q.R;”, this rule requires P to
be a root library unit, and Q to be a library unit (because those are
the things that are directly visible and visible). Note that visibility
does not apply between the “end” and the “;”.
Physically nested declarations are not visible
at these places.
Although Standard is visible at these places,
it is impossible to name it, since it is not directly visible, and it
has no parent.
Only compilation units defining limited views can
be mentioned in a limited_with_clause,
while only compilation units defining full views (that is, the explicit
declarations) can be mentioned in a nonlimited_with_clause.
This resolves the conflict inherent in having two compilation units with
the same defining name.
The “notwithstanding” part allows “with
A.B;” where A is a generic library package and B is one of its
(generic) children. This is necessary because it is not normally legal
to use an expanded name to reach inside a generic package.
that is within a context_clause
mentioned in a previous with_clause
of the same context_clause
is visible, and each root library_item
so mentioned is directly visible. In addition, within such a use_clause
if a given declaration is visible or directly visible, each declaration
that occurs immediately within the given declaration's visible part is
also visible. No other declarations are visible or directly visible.
Note the word “same”.
For example, if a with_clause
on a declaration mentions X, this does not make X visible in use_clause
that are on the body. The reason for this rule is the one-pass context_clause
Language Design Principle.
Note that the second part of the rule does not
appears at the place of a compilation unit, the immediately preceding
and each of its ancestors is visible. The ancestor root library_item
is directly visible.
Reason: This rule
allows with A.B; and pragma Elaborate(A.B); where A is
a generic library package and B is one of its (generic) children. This
is necessary because it is not normally legal to use an expanded name
to reach inside a generic package.
Wording Changes from Ada 83
We considered making the visibility rules within
follow from the context of compilation. However, this attempt failed
for various reasons. For example, it would require use_clause
to be within the declarative region of Standard, which sounds suspiciously
like a kludge. And we would still need a special rule to prevent seeing
things (in our own context_clause
that were with-ed by our parent, etc.
Wording Changes from Ada 95
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe