<p>Finally, within the declarative region associated with a construct other than a record type declaration, any declaration that occurs immediately within the region and that also occurs textually within the construct is visible by selection at the place of the suffix of an expanded name whose prefix denotes the construct.
<p>Where it is not visible by selection, a visible declaration is said to be <i>directly visible</i>.  A declaration is said to be directly visible within a certain part of its immediate scope; this part extends to the end of the immediate scope of the declaration but excludes places where the declaration is hidden as explained in the following paragraphs.  In addition, a declaration occurring immediately within the visible part of a package can be made directly visible by means of a use clause according to the rules described in   <a href = "1076_10.HTM#10.4"> 10.4 </a>  .
<p>A declaration is said to be <i>hidden</i> within (part of) an inner declarative region if the inner region contains a homograph of this declaration; the outer declaration is then hidden within the immediate scope of the inner homograph.  Each of two declarations is said to be a <i>homograph</i> of the other if both declarations have the same identifier, operator symbol, or character literal, and if overloading is allowed for at most one of the two.  If overloading is allowed for both declarations, then each of the two is a homograph of the other if they have the same identifier, operator symbol, or character literal, as well as the same parameter and result type profile (see   <a href = "1076_3.HTM#3.1.1"> 3.1.1 </a>  ).
<p>Within the specification of a subprogram, every declaration with the same designator as the subprogram is hidden.  Where hidden in this manner, a declaration is visible neither by selection nor directly.
<p>Two declarations that occur immediately within the same declarative region must not be homographs, unless exactly one of them is the implicit declaration of a predefined operation.  In such cases, a predefined operation is always hidden by the other homograph.  Where hidden in this manner, an implicit declaration is hidden within the entire scope of the other declaration (regardless of which declaration occurs first); the implicit declaration is visible neither by selection nor directly.
<p>Whenever a declaration with a certain identifier is visible from a given point, the identifier and the named entity (if any) are also said to be visible from that point.  Direct visibility and visibility by selection are likewise defined for character literals and operator symbols.  An operator is directly visible if and only if the corresponding operator declaration is directly visible.
<p>In addition to the above rules, any declaration that is visible by selection at the end of the declarative part of a given (external or internal) block is visible by selection in a configuration declaration that configures the given block.
<p>In addition, any declaration that is directly visible at the end of the declarative part of a given block is directly visible in a block configuration that configures the given block.  This rule holds unless a use clause that makes a homograph of the declaration potentially visible (see   <a href = "1076_10.HTM#10.4"> 10.4 </a>  ) appears in the corresponding configuration declaration, and if the scope of that use clause encompasses all or part of those configuration items.  If such a use clause appears, then the declaration will be directly visible within the corresponding configuration items, except at those places that fall within the scope of the additional use clause.  At such places, neither name will be directly visible.
<p>If a component configuration appears as a configuration item immediately within a block configuration that configures a given block, and if a given declaration is visible by selection at the end of the declarative part of that block, then the given declaration is visible by selection from the beginning to the end of the declarative region associated with the given component configuration.  A similar rule applies to a block configuration that appears as a configuration item immediately within another block configuration, provided that the contained block configuration configures an internal block.
<p>If a component configuration appears as a configuration item immediately within a block configuration that configures a given block, and if a given declaration is directly visible at the end of the declarative part of that block, then the given declaration is visible by selection from the beginning to the end of the declarative region associated with the given component configuration.  A similar rule applies to a block configuration that appears as a configuration item immediately within another block configuration, provided that the contained block configuration configures an internal block.  Furthermore, the visibility of declarations made directly visible by a use clause within a block is similarly extended.  Finally, the visibility of a logical library name corresponding to a design library directly visible at the end of a block is similarly extended.  The rules of this paragraph hold unless a use clause that makes a homograph of the declaration potentially visible appears in the corresponding block configuration, and if the scope of that use clause encompasses all or part of those configuration items.  If such a use clause appears, then the declaration will be directly visible within the corresponding configuration items, except at those places that fall within the scope of the additional use clause.  At such places, neither name will be directly visible.
<p>NOTES
<p>1--The same identifier, character literal, or operator symbol may occur indifferent declarations and may thus be associated with different named entities, even if the scopes of these declarations overlap.  Overlap of the scopes of declarations with the same identifier, character literal, or operator symbol can result from overloading of subprograms and of enumeration literals.  Such overlaps can also occur for named entities declared in the visible parts of packages and for formal generics and ports, record elements, and formal parameters, where there is overlap of the scopes of the enclosing package declarations, entity interfaces, record type declarations, or subprogram declarations.  Finally, overlapping scopes can result from nesting.
<p>2--The rules defining immediate scope, hiding, and visibility imply that a reference to an identifier, character literal, or operator symbol within its own declaration is illegal (except for design units).  The identifier,character literal, or operator symbol hides outer homographs within its immediate scope--that is, from the start of the declaration.  On the other hand, the identifier, character literal, or operator symbol is visible only after the end of the declaration (again, except for design units).  For this reason, all but the last of the following declarations are illegal:
<pre>         <b> </b><b><i>constant</i></b><i> K: INTEGER := K*K;</i><b><i>             </i></b><i> --  Illegal</i><b>
          </b><b><i>constant </i></b><i>T: T;</i><b><i>                          </i></b><i> --  Illegal</i><b>
        </b><i>  </i><b><i>procedure</i></b> <i>P (X: P);</i><b><i>                    </i></b><i>  --  Illegal</i><b>
          </b><b><i>function</i></b><b> </b><i>Q (X: REAL := Q)</i> <i><b>return</b> Q;</i><b><i>    </i></b><i>  --  Illegal</i>
       <b>   procedure</b> R (R: REAL);                   --  Legal (although perhaps confusing)
<i>Example:</i></pre>
<pre>   L1:  <b>block</b>
               <b>signal</b> A,B: Bit ;
          <b>begin</b>
          L2:  <b>block</b>
                   <b>signal</b> B: Bit ;                           --  An inner homograph of B.
               <b>begin</b>
                   A &lt;= B <b>after</b> 5 ns;                        --  Means L1.A &lt;= L2.B
                   B &lt;= L1.B <b>after</b> 10 ns;                    --  Means L2.B &lt;= L1.B
               <b>end block</b> ;
                   B &lt;= A <b>after</b> 15 ns;                       --  Means L1.B &lt;= L1.A
          <b>end block</b> ;
</pre>
<h2><a name="10.4">  <a href = "1076_10.HTM#10.4"> 10.4 </a>   Use clauses</a></h2>
<p>A use clause achieves direct visibility of declarations that are visible by selection.
<pre>     use_clause ::=
         <b>use</b> selected_name { , selected_name } ;
</pre>
<p>Each selected name in a use clause identifies one or more declarations that will potentially become directly visible.  If the suffix of the selected name is a simple name, character literal, or operator symbol, then the selected name identifies only the declaration(s) of that simple name, character literal, or operator symbol contained within the package or library denoted by the prefix of the selected name.  If  the suffix is the reserved word <b>all</b>, then the selected name identifies all declarations that are contained within the package or library denoted by the prefix of the selected name.
<p>For each use clause, there is a certain region of text called the <i>scope</i> of the use clause.  This region starts immediately after the use clause.  If a use clause is a declarative item of some declarative region, the scope of the clause extends to the end of the declarative region.  If a use clause occurs within the context clause of a design unit, the scope of the use clause extends to the end of the declarative region associated with the design unit.  The scope of a use clause may additionally extend into a configuration declaration(see   <a href = "1076_10.HTM#10.2"> 10.2 </a>  ).
<p>In order to determine which declarations are made directly visible at a given place by use clauses, consider the set of declarations identified by all use clauses whose scopes enclose this place.  Any declaration in this set is a potentially visible declaration.  A potentially visible declaration is actually made directly visible except in the following two cases:
<ol type="a">
<li>A potentially visible declaration is not made directly visible if the place considered is within the immediate scope of a homograph of the declaration.<br>
<p><li>Potentially visible declarations that have the same designator are not made directly visible unless each of them is either an enumeration literal specification or the declaration of a subprogram (either by a subprogram declaration or by an implicit declaration).
</ol>
<p>NOTES
<p>1--These rules guarantee that a declaration that is made directly visible by a use clause cannot hide an otherwise directly visible declaration.
<p>2--If a named entity X declared in package P is made potentially visible within a package Q (e.g., by the inclusion of the clause "<b>use</b> P.X;" in the context clause of package Q), and the context clause for design unit R includes the clause "<b>use</b> Q.<b>all</b>;", this does not imply that X will be potentially visible in R.  Only those named entities that are actually declared in package Q will be potentially visible in design unit R (in the absence of any other use clauses).
<h2><a name="10.5">  <a href = "1076_10.HTM#10.5"> 10.5 </a>   The context of overload resolution</a></h2>
<p>Overloading is defined for names, subprograms, and enumeration literals.
<p>For overloaded entities, overload resolution determines the actual meaning that an occurrence of an identifier or a character literal has whenever the visibility rules have determined that more than one meaning is acceptable at the place of this occurrence; overload resolution likewise determines the actual meaning of an occurrence of an operator or basic operation (see the introduction to Section 3).
<p>At such a place, all visible declarations are considered.  The occurrence is only legal if there is exactly one interpretation of each constituent of the innermost complete context; a <i>complete context</i> is either a declaration,a specification, or a statement.
<p>When considering possible interpretations of a complete context, the only rules considered are the syntax rules, the scope and visibility rules, and the rules of the form described below.
<ol type="a">
<li>Any rule that requires a name or expression to have a certain type or to have the same type as another name or expression.<br>
<p><li>Any rule that requires the type of a name or expression to be a type of a certain class; similarly, any rule that requires a certain type to be a discrete, integer, floating point, physical, universal, character, or Boolean type.<br>
<p><li>Any rule that requires a prefix to be appropriate for a certain type.<br>
<p><li>The rules that require the type of an aggregate or string literal to be determinable solely from the enclosing complete context.  Similarly, the rules that require the type of the prefix of an attribute, the type of the expression of a case statement, or the type of the operand of a type conversion to be determinable independently of the context.<br>
<p><li>The rules given for the resolution of overloaded subprogram calls; for the implicit conversions of universal expressions; for the interpretation of discrete ranges with bounds having a universal type; and for the interpretation of an expanded name whose prefix denotes a subprogram.<br>
<p><li>The rules given for the requirements on the return type, the number of formal parameters, and the types of the formal parameters of the subprogram denoted by the resolution function name (see   <a href = "1076_2.HTM#2.4"> 2.4 </a>  ).
</ol>
<p>NOTES
<p>1--If there is only one possible interpretation of an occurrence of an identifier, character literal, operator symbol, or string, that occurrence denotes the corresponding named entity.  However, this condition does not mean that the occurrence is necessarily legal since other requirements exist that are not considered for overload resolution: for example, the fact that the expression is static, the parameter modes, conformance rules, the use of named association in an indexed name, the use of <b>open</b> in an indexed name, the use of a slice as an actual to a function call, and so forth.
<p>2--A loop parameter specification is a declaration, and hence a complete context.
<p>3--Rules that require certain constructs to have the same parameter and result type profile fall under category a.  The same holds for rules that require conformance of two constructs, since conformance requires that corresponding names be given the same meaning by the visibility and overloading rules.
<HR>
<a href="../../HTML/HOMEPG.HTM"><img src="HP.GIF"  border=0></a>
<a href="1076_TOC.HTM"><img src="TOP.GIF" BORDER=0></a>
<a href="1076_9.HTM"><img src="LEFT.GIF" BORDER=0></a>
<a href="1076_11.HTM"><img src="RIGHT.GIF" BORDER=0></a>
</body></html>