8 Visibility Rules 1/3 The rules defining the scope of declarations and the rules defining which identifiers, character_literals, and operator_symbols are visible at (or from) various places in the text of the program are described in this clause. The formulation of these rules uses the notion of a declarative region. 2/3 As explained in Clause 3, a declaration declares a view of an entity and associates a defining name with that view. The view comprises an identification of the viewed entity, and possibly additional properties. A usage name denotes a declaration. It also denotes the view declared by that declaration, and denotes the entity of that view. Thus, two different usage names might denote two different views of the same entity; in this case they denote the same entity. 8.1 Declarative Region Static Semantics 1 For each of the following constructs, there is a portion of the program text called its declarative region, within which nested declarations can occur: 2 * any declaration, other than that of an enumeration type, that is not a completion of a previous declaration; 2.1/4 * an access_definition; 3 * a block_statement; 4 * a loop_statement; 4.1/3 * a quantified_expression; 4.2/3 * an extended_return_statement; 5 * an accept_statement; 6 * an exception_handler. 7 The declarative region includes the text of the construct together with additional text determined (recursively), as follows: 8 * If a declaration is included, so is its completion, if any. 9 * If the declaration of a library unit (including Standard - see 10.1.1) is included, so are the declarations of any child units (and their completions, by the previous rule). The child declarations occur after the declaration. 10 * If a body_stub is included, so is the corresponding subunit. 11 * If a type_declaration is included, then so is a corresponding record_representation_clause, if any. 12 The declarative region of a declaration is also called the declarative region of any view or entity declared by the declaration. 13 A declaration occurs immediately within a declarative region if this region is the innermost declarative region that encloses the declaration (the immediately enclosing declarative region), not counting the declarative region (if any) associated with the declaration itself. 14 A declaration is local to a declarative region if the declaration occurs immediately within the declarative region. An entity is local to a declarative region if the entity is declared by a declaration that is local to the declarative region. 15 A declaration is global to a declarative region if the declaration occurs immediately within another declarative region that encloses the declarative region. An entity is global to a declarative region if the entity is declared by a declaration that is global to the declarative region. NOTES 16 1 The children of a parent library unit are inside the parent's declarative region, even though they do not occur inside the parent's declaration or body. This implies that one can use (for example) "P.Q" to refer to a child of P whose defining name is Q, and that after "use P;" Q can refer (directly) to that child. 17 2 As explained above and in 10.1.1, " Compilation Units - Library Units", all library units are descendants of Standard, and so are contained in the declarative region of Standard. They are not inside the declaration or body of Standard, but they are inside its declarative region. 18 3 For a declarative region that comes in multiple parts, the text of the declarative region does not contain any text that might appear between the parts. Thus, when a portion of a declarative region is said to extend from one place to another in the declarative region, the portion does not contain any text that might appear between the parts of the declarative region. 8.2 Scope of Declarations 1 For each declaration, the language rules define a certain portion of the program text called the scope of the declaration. The scope of a declaration is also called the scope of any view or entity declared by the declaration. Within the scope of an entity, and only there, there are places where it is legal to refer to the declared entity. These places are defined by the rules of visibility and overloading. Static Semantics 2 The immediate scope of a declaration is a portion of the declarative region immediately enclosing the declaration. The immediate scope starts at the beginning of the declaration, except in the case of an overloadable declaration, in which case the immediate scope starts just after the place where the profile of the callable entity is determined (which is at the end of the _specification for the callable entity, or at the end of the generic_instantiation if an instance). The immediate scope extends to the end of the declarative region, with the following exceptions: 3 * The immediate scope of a library_item includes only its semantic dependents. 4 * The immediate scope of a declaration in the private part of a library unit does not include the visible part of any public descendant of that library unit. 5 The visible part of (a view of) an entity is a portion of the text of its declaration containing declarations that are visible from outside. The private part of (a view of) an entity that has a visible part contains all declarations within the declaration of (the view of) the entity, except those in the visible part; these are not visible from outside. Visible and private parts are defined only for these kinds of entities: callable entities, other program units, and composite types. 6 * The visible part of a view of a callable entity is its profile. 7 * The visible part of a composite type other than a task or protected type consists of the declarations of all components declared (explicitly or implicitly) within the type_declaration. 8 * The visible part of a generic unit includes the generic_formal_part. For a generic package, it also includes the first list of basic_declarative_items of the package_specification. For a generic subprogram, it also includes the profile. 9 * The visible part of a package, task unit, or protected unit consists of declarations in the program unit's declaration other than those following the reserved word private, if any; see 7.1 and 12.7 for packages, 9.1 for task units, and 9.4 for protected units. 10 The scope of a declaration always contains the immediate scope of the declaration. In addition, for a given declaration that occurs immediately within the visible part of an outer declaration, or is a public child of an outer declaration, the scope of the given declaration extends to the end of the scope of the outer declaration, except that the scope of a library_item includes only its semantic dependents. 10.1/3 The scope of an attribute_definition_clause is identical to the scope of a declaration that would occur at the point of the attribute_definition_clause. The scope of an aspect_specification is identical to the scope of the associated declaration. 11 The immediate scope of a declaration is also the immediate scope of the entity or view declared by the declaration. Similarly, the scope of a declaration is also the scope of the entity or view declared by the declaration. 12/4 The immediate scope of a pragma that is not used as a configuration pragma is defined to be the region extending from immediately after the pragma to the end of the declarative region immediately enclosing the pragma. NOTES 13/3 4 There are notations for denoting visible declarations that are not directly visible. For example, parameter_specifications are in the visible part of a subprogram_declaration so that they can be used in named-notation calls appearing outside the called subprogram. For another example, declarations of the visible part of a package can be denoted by expanded names appearing outside the package, and can be made directly visible by a use_clause. 8.3 Visibility 1 The visibility rules, given below, determine which declarations are visible and directly visible at each place within a program. The visibility rules apply to both explicit and implicit declarations. Static Semantics 2 A declaration is defined to be directly visible at places where a name consisting of only an identifier or operator_symbol is sufficient to denote the declaration; that is, no selected_component notation or special context (such as preceding => in a named association) is necessary to denote the declaration. A declaration is defined to be visible wherever it is directly visible, as well as at other places where some name (such as a selected_component) can denote the declaration. 3 The syntactic category direct_name is used to indicate contexts where direct visibility is required. The syntactic category selector_name is used to indicate contexts where visibility, but not direct visibility, is required. 4 There are two kinds of direct visibility: immediate visibility and use-visibility. A declaration is immediately visible at a place if it is directly visible because the place is within its immediate scope. A declaration is use-visible if it is directly visible because of a use_clause (see 8.4). Both conditions can apply. 5 A declaration can be hidden, either from direct visibility, or from all visibility, within certain parts of its scope. Where hidden from all visibility, it is not visible at all (neither using a direct_name nor a selector_name). Where hidden from direct visibility, only direct visibility is lost; visibility using a selector_name is still possible. 6 Two or more declarations are overloaded if they all have the same defining name and there is a place where they are all directly visible. 7 The declarations of callable entities (including enumeration literals) are overloadable, meaning that overloading is allowed for them. 8 Two declarations are homographs if they have the same defining name, and, if both are overloadable, their profiles are type conformant. An inner declaration hides any outer homograph from direct visibility. 9/1 Two homographs are not generally allowed immediately within the same declarative region unless one overrides the other (see Legality Rules below). The only declarations that are overridable are the implicit declarations for predefined operators and inherited primitive subprograms. A declaration overrides another homograph that occurs immediately within the same declarative region in the following cases: 10/1 * A declaration that is not overridable overrides one that is overridable, regardless of which declaration occurs first; 11 * The implicit declaration of an inherited operator overrides that of a predefined operator; 12 * An implicit declaration of an inherited subprogram overrides a previous implicit declaration of an inherited subprogram. 12.1/2 * If two or more homographs are implicitly declared at the same place: 12.2/2 * If at least one is a subprogram that is neither a null procedure nor an abstract subprogram, and does not require overriding (see 3.9.3), then they override those that are null procedures, abstract subprograms, or require overriding. If more than one such homograph remains that is not thus overridden, then they are all hidden from all visibility. 12.3/2 * Otherwise (all are null procedures, abstract subprograms, or require overriding), then any null procedure overrides all abstract subprograms and all subprograms that require overriding; if more than one such homograph remains that is not thus overridden, then if they are all fully conformant with one another, one is chosen arbitrarily; if not, they are all hidden from all visibility. 13 * For an implicit declaration of a primitive subprogram in a generic unit, there is a copy of this declaration in an instance. However, a whole new set of primitive subprograms is implicitly declared for each type declared within the visible part of the instance. These new declarations occur immediately after the type declaration, and override the copied ones. The copied ones can be called only from within the instance; the new ones can be called only from outside the instance, although for tagged types, the body of a new one can be executed by a call to an old one. 14 A declaration is visible within its scope, except where hidden from all visibility, as follows: 15 * An overridden declaration is hidden from all visibility within the scope of the overriding declaration. 16 * A declaration is hidden from all visibility until the end of the declaration, except: 17 * For a record type or record extension, the declaration is hidden from all visibility only until the reserved word record; 18/3 * For a package_declaration, generic_package_declaration, subprogram_- body, or expression_function_declaration, the declaration is hidden from all visibility only until the reserved word is of the declaration; 18.1/2 * For a task declaration or protected declaration, the declaration is hidden from all visibility only until the reserved word with of the declaration if there is one, or the reserved word is of the declaration if there is no with. 19 * If the completion of a declaration is a declaration, then within the scope of the completion, the first declaration is hidden from all visibility. Similarly, a discriminant_specification or parameter_- specification is hidden within the scope of a corresponding discriminant_specification or parameter_specification of a corresponding completion, or of a corresponding accept_statement. 20/2 * The declaration of a library unit (including a library_unit_renaming_declaration) is hidden from all visibility at places outside its declarative region that are not within the scope of a nonlimited_with_clause that mentions it. The limited view of a library package is hidden from all visibility at places that are not within the scope of a limited_with_clause that mentions it; in addition, the limited view is hidden from all visibility within the declarative region of the package, as well as within the scope of any nonlimited_with_clause that mentions the package. Where the declaration of the limited view of a package is visible, any name that denotes the package denotes the limited view, including those provided by a package renaming. 20.1/2 * For each declaration or renaming of a generic unit as a child of some parent generic package, there is a corresponding declaration nested immediately within each instance of the parent. Such a nested declaration is hidden from all visibility except at places that are within the scope of a with_clause that mentions the child. 21 A declaration with a defining_identifier or defining_operator_symbol is immediately visible (and hence directly visible) within its immediate scope except where hidden from direct visibility, as follows: 22 * A declaration is hidden from direct visibility within the immediate scope of a homograph of the declaration, if the homograph occurs within an inner declarative region; 23 * A declaration is also hidden from direct visibility where hidden from all visibility. 23.1/3 An attribute_definition_clause or an aspect_specification is visible everywhere within its scope. Name Resolution Rules 24 A direct_name shall resolve to denote a directly visible declaration whose defining name is the same as the direct_name. A selector_name shall resolve to denote a visible declaration whose defining name is the same as the selector_name. 25 These rules on visibility and direct visibility do not apply in a context_clause, a parent_unit_name, or a pragma that appears at the place of a compilation_unit. For those contexts, see the rules in 10.1.6, " Environment-Level Visibility Rules". Legality Rules 26/2 A nonoverridable declaration is illegal if there is a homograph occurring immediately within the same declarative region that is visible at the place of the declaration, and is not hidden from all visibility by the nonoverridable declaration. In addition, a type extension is illegal if somewhere within its immediate scope it has two visible components with the same name. Similarly, the context_clause for a compilation unit is illegal if it mentions (in a with_clause) some library unit, and there is a homograph of the library unit that is visible at the place of the compilation unit, and the homograph and the mentioned library unit are both declared immediately within the same declarative region. These rules also apply to dispatching operations declared in the visible part of an instance of a generic unit. However, they do not apply to other overloadable declarations in an instance; such declarations may have type conformant profiles in the instance, so long as the corresponding declarations in the generic were not type conformant. NOTES 27 5 Visibility for compilation units follows from the definition of the environment in 10.1.4, except that it is necessary to apply a with_clause to obtain visibility to a library_unit_declaration or library_unit_renaming_declaration. 28 6 In addition to the visibility rules given above, the meaning of the occurrence of a direct_name or selector_name at a given place in the text can depend on the overloading rules (see 8.6). 29 7 Not all contexts where an identifier, character_literal, or operator_symbol are allowed require visibility of a corresponding declaration. Contexts where visibility is not required are identified by using one of these three syntactic categories directly in a syntax rule, rather than using direct_name or selector_name. 8.3.1 Overriding Indicators 1/2 An overriding_indicator is used to declare that an operation is intended to override (or not override) an inherited operation. Syntax 2/2 overriding_indicator ::= [not] overriding Legality Rules 3/3 If an abstract_subprogram_declaration, null_procedure_declaration, expression_function_declaration, subprogram_body, subprogram_body_stub, subprogram_renaming_declaration, generic_instantiation of a subprogram, or subprogram_declaration other than a protected subprogram has an overriding_- indicator, then: 4/2 * the operation shall be a primitive operation for some type; 5/2 * if the overriding_indicator is overriding, then the operation shall override a homograph at the place of the declaration or body; 6/2 * if the overriding_indicator is not overriding, then the operation shall not override any homograph (at any place). 7/2 In addition to the places where Legality Rules normally apply, these rules also apply in the private part of an instance of a generic unit. NOTES 8/2 8 Rules for overriding_indicators of task and protected entries and of protected subprograms are found in 9.5.2 and 9.4, respectively. Examples 9/2 The use of overriding_indicators allows the detection of errors at compile-time that otherwise might not be detected at all. For instance, we might declare a security queue derived from the Queue interface of 3.9.4 as: 10/2 type Security_Queue is new Queue with record ...; 11/2 overriding procedure Append(Q : in out Security_Queue; Person : in Person_Name); 12/2 overriding procedure Remove_First(Q : in out Security_Queue; Person : in Person_Name); 13/2 overriding function Cur_Count(Q : in Security_Queue) return Natural; 14/2 overriding function Max_Count(Q : in Security_Queue) return Natural; 15/2 not overriding procedure Arrest(Q : in out Security_Queue; Person : in Person_Name); 16/2 The first four subprogram declarations guarantee that these subprograms will override the four subprograms inherited from the Queue interface. A misspelling in one of these subprograms will be detected by the implementation. Conversely, the declaration of Arrest guarantees that this is a new operation. 8.4 Use Clauses 1 A use_package_clause achieves direct visibility of declarations that appear in the visible part of a package; a use_type_clause achieves direct visibility of the primitive operators of a type. Syntax 2 use_clause ::= use_package_clause | use_type_clause 3 use_package_clause ::= use package_name {, package_name}; 4/3 use_type_clause ::= use [all] type subtype_mark {, subtype_mark}; Legality Rules 5/2 A package_name of a use_package_clause shall denote a nonlimited view of a package. Static Semantics 6 For each use_clause, there is a certain region of text called the scope of the use_clause. For a use_clause within a context_clause of a library_unit_declaration or library_unit_renaming_declaration, the scope is the entire declarative region of the declaration. For a use_clause within a context_clause of a body, the scope is the entire body and any subunits (including multiply nested subunits). The scope does not include context_clauses themselves. 7 For a use_clause immediately within a declarative region, the scope is the portion of the declarative region starting just after the use_clause and extending to the end of the declarative region. However, the scope of a use_clause in the private part of a library unit does not include the visible part of any public descendant of that library unit. 7.1/2 A package is named in a use_package_clause if it is denoted by a package_name of that clause. A type is named in a use_type_clause if it is determined by a subtype_mark of that clause. 8/3 For each package named in a use_package_clause whose scope encloses a place, each declaration that occurs immediately within the declarative region of the package is potentially use-visible at this place if the declaration is visible at this place. For each type T or T'Class named in a use_type_clause whose scope encloses a place, the declaration of each primitive operator of type T is potentially use-visible at this place if its declaration is visible at this place. If a use_type_clause whose scope encloses a place includes the reserved word all, then the following entities are also potentially use-visible at this place if the declaration of the entity is visible at this place: 8.1/3 * Each primitive subprogram of T including each enumeration literal (if any); 8.2/3 * Each subprogram that is declared immediately within the declarative region in which an ancestor type of T is declared and that operates on a class-wide type that covers T. 8.3/3 Certain implicit declarations may become potentially use-visible in certain contexts as described in 12.6. 9 A declaration is use-visible if it is potentially use-visible, except in these naming-conflict cases: 10 * A potentially use-visible declaration is not use-visible if the place considered is within the immediate scope of a homograph of the declaration. 11 * Potentially use-visible declarations that have the same identifier are not use-visible unless each of them is an overloadable declaration. Dynamic Semantics 12 The elaboration of a use_clause has no effect. Examples 13 Example of a use clause in a context clause: 14 with Ada.Calendar; use Ada; 15 Example of a use type clause: 16 use type Rational_Numbers.Rational; -- see 7.1 Two_Thirds: Rational_Numbers.Rational := 2/3; 8.5 Renaming Declarations 1 A renaming_declaration declares another name for an entity, such as an object, exception, package, subprogram, entry, or generic unit. Alternatively, a subprogram_renaming_declaration can be the completion of a previous subprogram_declaration. Syntax 2 renaming_declaration ::= object_renaming_declaration | exception_renaming_declaration | package_renaming_declaration | subprogram_renaming_declaration | generic_renaming_declaration Dynamic Semantics 3 The elaboration of a renaming_declaration evaluates the name that follows the reserved word renames and thereby determines the view and entity denoted by this name (the renamed view and renamed entity). A name that denotes the renaming_declaration denotes (a new view of) the renamed entity. NOTES 4 9 Renaming may be used to resolve name conflicts and to act as a shorthand. Renaming with a different identifier or operator_symbol does not hide the old name; the new name and the old name need not be visible at the same places. 5 10 A task or protected object that is declared by an explicit object_declaration can be renamed as an object. However, a single task or protected object cannot be renamed since the corresponding type is anonymous (meaning it has no nameable subtypes). For similar reasons, an object of an anonymous array or access type cannot be renamed. 6 11 A subtype defined without any additional constraint can be used to achieve the effect of renaming another subtype (including a task or protected subtype) as in 7 subtype Mode is Ada.Text_IO.File_Mode; 8.5.1 Object Renaming Declarations 1 An object_renaming_declaration is used to rename an object. Syntax 2/3 object_renaming_declaration ::= defining_identifier : [null_exclusion] subtype_mark renames object_name [aspect_specification]; | defining_identifier : access_definition renames object_name [aspect_specification]; Name Resolution Rules 3/2 The type of the object_name shall resolve to the type determined by the subtype_mark, or in the case where the type is defined by an access_definition, to an anonymous access type. If the anonymous access type is an access-to-object type, the type of the object_name shall have the same designated type as that of the access_definition. If the anonymous access type is an access-to-subprogram type, the type of the object_name shall have a designated profile that is type conformant with that of the access_definition. Legality Rules 4 The renamed entity shall be an object. 4.1/2 In the case where the type is defined by an access_definition, the type of the renamed object and the type defined by the access_definition: 4.2/2 * shall both be access-to-object types with statically matching designated subtypes and with both or neither being access-to-constant types; or 4.3/2 * shall both be access-to-subprogram types with subtype conformant designated profiles. 4.4/2 For an object_renaming_declaration with a null_exclusion or an access_definition that has a null_exclusion: 4.5/2 * if the object_name denotes a generic formal object of a generic unit G, and the object_renaming_declaration occurs within the body of G or within the body of a generic unit declared within the declarative region of G, then the declaration of the formal object of G shall have a null_exclusion; 4.6/2 * otherwise, the subtype of the object_name shall exclude null. In addition to the places where Legality Rules normally apply (see 12.3 ), this rule applies also in the private part of an instance of a generic unit. 5/3 The renamed entity shall not be a subcomponent that depends on discriminants of an object whose nominal subtype is unconstrained unless the object is known to be constrained. A slice of an array shall not be renamed if this restriction disallows renaming of the array. In addition to the places where Legality Rules normally apply, these rules apply also in the private part of an instance of a generic unit. Static Semantics 6/2 An object_renaming_declaration declares a new view of the renamed object whose properties are identical to those of the renamed view. Thus, the properties of the renamed object are not affected by the renaming_declaration. In particular, its value and whether or not it is a constant are unaffected; similarly, the null exclusion or constraints that apply to an object are not affected by renaming (any constraint implied by the subtype_mark or access_definition of the object_renaming_declaration is ignored). Examples 7 Example of renaming an object: 8 declare L : Person renames Leftmost_Person; -- see 3.10.1 begin L.Age := L.Age + 1; end; 8.5.2 Exception Renaming Declarations 1 An exception_renaming_declaration is used to rename an exception. Syntax 2/3 exception_renaming_declaration ::= defining_identifier : exception renames exception_name [aspect_specification]; Legality Rules 3 The renamed entity shall be an exception. Static Semantics 4 An exception_renaming_declaration declares a new view of the renamed exception. Examples 5 Example of renaming an exception: 6 EOF : exception renames Ada.IO_Exceptions.End_Error; -- see A.13 8.5.3 Package Renaming Declarations 1 A package_renaming_declaration is used to rename a package. Syntax 2/3 package_renaming_declaration ::= package defining_program_unit_name renames package_name [aspect_specification]; Legality Rules 3 The renamed entity shall be a package. 3.1/2 If the package_name of a package_renaming_declaration denotes a limited view of a package P, then a name that denotes the package_renaming_declaration shall occur only within the immediate scope of the renaming or the scope of a with_clause that mentions the package P or, if P is a nested package, the innermost library package enclosing P. Static Semantics 4 A package_renaming_declaration declares a new view of the renamed package. 4.1/2 At places where the declaration of the limited view of the renamed package is visible, a name that denotes the package_renaming_declaration denotes a limited view of the package (see 10.1.1). Examples 5 Example of renaming a package: 6 package TM renames Table_Manager; 8.5.4 Subprogram Renaming Declarations 1/3 A subprogram_renaming_declaration can serve as the completion of a subprogram_declaration; such a renaming_declaration is called a renaming-as-body. A subprogram_renaming_declaration that is not a completion is called a renaming-as-declaration, and is used to rename a subprogram (possibly an enumeration literal) or an entry. Syntax 2/3 subprogram_renaming_declaration ::= [overriding_indicator] subprogram_specification renames callable_entity_name [aspect_specification]; Name Resolution Rules 3 The expected profile for the callable_entity_name is the profile given in the subprogram_specification. Legality Rules 4/3 The profile of a renaming-as-declaration shall be mode conformant, with that of the renamed callable entity. 4.1/2 For a parameter or result subtype of the subprogram_specification that has an explicit null_exclusion: 4.2/2 * if the callable_entity_name denotes a generic formal subprogram of a generic unit G, and the subprogram_renaming_declaration occurs within the body of a generic unit G or within the body of a generic unit declared within the declarative region of the generic unit G, then the corresponding parameter or result subtype of the formal subprogram of G shall have a null_exclusion; 4.3/2 * otherwise, the subtype of the corresponding parameter or result type of the renamed callable entity shall exclude null. In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit. 5/3 The profile of a renaming-as-body shall conform fully to that of the declaration it completes. If the renaming-as-body completes that declaration before the subprogram it declares is frozen, the profile shall be mode conformant with that of the renamed callable entity and the subprogram it declares takes its convention from the renamed subprogram; otherwise, the profile shall be subtype conformant with that of the renamed callable entity and the convention of the renamed subprogram shall not be Intrinsic. A renaming-as-body is illegal if the declaration occurs before the subprogram whose declaration it completes is frozen, and the renaming renames the subprogram itself, through one or more subprogram renaming declarations, none of whose subprograms has been frozen. 5.1/2 The callable_entity_name of a renaming shall not denote a subprogram that requires overriding (see 3.9.3). 5.2/2 The callable_entity_name of a renaming-as-body shall not denote an abstract subprogram. 6 A name that denotes a formal parameter of the subprogram_specification is not allowed within the callable_entity_name. Static Semantics 7 A renaming-as-declaration declares a new view of the renamed entity. The profile of this new view takes its subtypes, parameter modes, and calling convention from the original profile of the callable entity, while taking the formal parameter names and default_expressions from the profile given in the subprogram_renaming_declaration. The new view is a function or procedure, never an entry. Dynamic Semantics 7.1/1 For a call to a subprogram whose body is given as a renaming-as-body, the execution of the renaming-as-body is equivalent to the execution of a subprogram_body that simply calls the renamed subprogram with its formal parameters as the actual parameters and, if it is a function, returns the value of the call. 8/3 For a call on a renaming of a dispatching subprogram that is overridden, if the overriding occurred before the renaming, then the body executed is that of the overriding declaration, even if the overriding declaration is not visible at the place of the renaming; otherwise, the inherited or predefined subprogram is called. A corresponding rule applies to a call on a renaming of a predefined equality operator for an untagged record type. Bounded (Run-Time) Errors 8.1/1 If a subprogram directly or indirectly renames itself, then it is a bounded error to call that subprogram. Possible consequences are that Program_Error or Storage_Error is raised, or that the call results in infinite recursion. NOTES 9 12 A procedure can only be renamed as a procedure. A function whose defining_designator is either an identifier or an operator_symbol can be renamed with either an identifier or an operator_symbol; for renaming as an operator, the subprogram specification given in the renaming_declaration is subject to the rules given in 6.6 for operator declarations. Enumeration literals can be renamed as functions; similarly, attribute_references that denote functions (such as references to Succ and Pred) can be renamed as functions. An entry can only be renamed as a procedure; the new name is only allowed to appear in contexts that allow a procedure name. An entry of a family can be renamed, but an entry family cannot be renamed as a whole. 10 13 The operators of the root numeric types cannot be renamed because the types in the profile are anonymous, so the corresponding specifications cannot be written; the same holds for certain attributes, such as Pos. 11 14 Calls with the new name of a renamed entry are procedure_call_statements and are not allowed at places where the syntax requires an entry_call_statement in conditional_ and timed_entry_calls, nor in an asynchronous_select; similarly, the Count attribute is not available for the new name. 12 15 The primitiveness of a renaming-as-declaration is determined by its profile, and by where it occurs, as for any declaration of (a view of) a subprogram; primitiveness is not determined by the renamed view. In order to perform a dispatching call, the subprogram name has to denote a primitive subprogram, not a nonprimitive renaming of a primitive subprogram. Examples 13 Examples of subprogram renaming declarations: 14 procedure My_Write(C : in Character) renames Pool(K).Write; -- see 4.1.3 15 function Real_Plus(Left, Right : Real ) return Real renames "+"; function Int_Plus (Left, Right : Integer) return Integer renames "+"; 16 function Rouge return Color renames Red; -- see 3.5.1 function Rot return Color renames Red; function Rosso return Color renames Rouge; 17 function Next(X : Color) return Color renames Color'Succ; -- see 3.5.1 18 Example of a subprogram renaming declaration with new parameter names: 19 function "*" (X,Y : Vector) return Real renames Dot_Product; -- see 6.1 20 Example of a subprogram renaming declaration with a new default expression: 21 function Minimum(L : Link := Head) return Cell renames Min_Cell; -- see 6.1 8.5.5 Generic Renaming Declarations 1 A generic_renaming_declaration is used to rename a generic unit. Syntax 2/3 generic_renaming_declaration ::= generic package defining_program_unit_name renames generic_package_name [aspect_specification]; | generic procedure defining_program_unit_name renames generic_procedure_name [aspect_specification]; | generic function defining_program_unit_name renames generic_function_name [aspect_specification]; Legality Rules 3 The renamed entity shall be a generic unit of the corresponding kind. Static Semantics 4 A generic_renaming_declaration declares a new view of the renamed generic unit. NOTES 5 16 Although the properties of the new view are the same as those of the renamed view, the place where the generic_renaming_declaration occurs may affect the legality of subsequent renamings and instantiations that denote the generic_renaming_declaration, in particular if the renamed generic unit is a library unit (see 10.1.1 ). Examples 6 Example of renaming a generic unit: 7 generic package Enum_IO renames Ada.Text_IO.Enumeration_IO; -- see A.10.10 8.6 The Context of Overload Resolution 1/3 Because declarations can be overloaded, it is possible for an occurrence of a usage name to have more than one possible interpretation; in most cases, ambiguity is disallowed. This subclause describes how the possible interpretations resolve to the actual interpretation. 2 Certain rules of the language (the Name Resolution Rules) are considered "overloading rules". If a possible interpretation violates an overloading rule, it is assumed not to be the intended interpretation; some other possible interpretation is assumed to be the actual interpretation. On the other hand, violations of nonoverloading rules do not affect which interpretation is chosen; instead, they cause the construct to be illegal. To be legal, there usually has to be exactly one acceptable interpretation of a construct that is a "complete context", not counting any nested complete contexts. 3 The syntax rules of the language and the visibility rules given in 8.3 determine the possible interpretations. Most type checking rules (rules that require a particular type, or a particular class of types, for example) are overloading rules. Various rules for the matching of formal and actual parameters are overloading rules. Name Resolution Rules 4 Overload resolution is applied separately to each complete context, not counting inner complete contexts. Each of the following constructs is a complete context: 5 * A context_item. 6 * A declarative_item or declaration. 7 * A statement. 8 * A pragma_argument_association. 9/4 * The selecting_expression of a case_statement or case_expression. 10 An (overall) interpretation of a complete context embodies its meaning, and includes the following information about the constituents of the complete context, not including constituents of inner complete contexts: 11 * for each constituent of the complete context, to which syntactic categories it belongs, and by which syntax rules; and 12 * for each usage name, which declaration it denotes (and, therefore, which view and which entity it denotes); and 13 * for a complete context that is a declarative_item, whether or not it is a completion of a declaration, and (if so) which declaration it completes. 14 A possible interpretation is one that obeys the syntax rules and the visibility rules. An acceptable interpretation is a possible interpretation that obeys the overloading rules, that is, those rules that specify an expected type or expected profile, or specify how a construct shall resolve or be interpreted. 15 The interpretation of a constituent of a complete context is determined from the overall interpretation of the complete context as a whole. Thus, for example, "interpreted as a function_call," means that the construct's interpretation says that it belongs to the syntactic category function_call. 16 Each occurrence of a usage name denotes the declaration determined by its interpretation. It also denotes the view declared by its denoted declaration, except in the following cases: 17/3 * If a usage name appears within the declarative region of a type_declaration and denotes that same type_declaration, then it denotes the current instance of the type (rather than the type itself); the current instance of a type is the object or value of the type that is associated with the execution that evaluates the usage name. Similarly, if a usage name appears within the declarative region of a subtype_declaration and denotes that same subtype_declaration, then it denotes the current instance of the subtype. These rules do not apply if the usage name appears within the subtype_mark of an access_definition for an access-to-object type, or within the subtype of a parameter or result of an access-to-subprogram type. 17.1/4 Within an aspect_specification for a type or subtype, the current instance represents a value of the type; it is not an object. The nominal subtype of this value is given by the subtype itself (the first subtype in the case of a type_declaration), prior to applying any predicate specified directly on the type or subtype. If the type or subtype is by-reference, the associated object with the value is the object associated (see 6.2) with the execution of the usage name. 18 * If a usage name appears within the declarative region of a generic_declaration (but not within its generic_formal_part) and it denotes that same generic_declaration, then it denotes the current instance of the generic unit (rather than the generic unit itself). See also 12.3. 19 A usage name that denotes a view also denotes the entity of that view. 20/2 The expected type for a given expression, name, or other construct determines, according to the type resolution rules given below, the types considered for the construct during overload resolution. The type resolution rules provide support for class-wide programming, universal literals, dispatching operations, and anonymous access types: 21 * If a construct is expected to be of any type in a class of types, or of the universal or class-wide type for a class, then the type of the construct shall resolve to a type in that class or to a universal type that covers the class. 22 * If the expected type for a construct is a specific type T, then the type of the construct shall resolve either to T, or: 23 * to T'Class; or 24 * to a universal type that covers T; or 25/2 * when T is a specific anonymous access-to-object type (see 3.10) with designated type D, to an access-to-object type whose designated type is D'Class or is covered by D; or 25.1/3 * when T is a named general access-to-object type (see 3.10) with designated type D, to an anonymous access-to-object type whose designated type covers or is covered by D; or 25.2/3 * when T is an anonymous access-to-subprogram type (see 3.10), to an access-to-subprogram type whose designated profile is type conformant with that of T. 26 In certain contexts, such as in a subprogram_renaming_declaration, the Name Resolution Rules define an expected profile for a given name; in such cases, the name shall resolve to the name of a callable entity whose profile is type conformant with the expected profile. Legality Rules 27/2 When a construct is one that requires that its expected type be a single type in a given class, the type of the construct shall be determinable solely from the context in which the construct appears, excluding the construct itself, but using the requirement that it be in the given class. Furthermore, the context shall not be one that expects any type in some class that contains types of the given class; in particular, the construct shall not be the operand of a type_conversion. 27.1/4 Other than for the tested_simple_expression of a membership test, if the expected type for a name or expression is not the same as the actual type of the name or expression, the actual type shall be convertible to the expected type (see 4.6); further, if the expected type is a named access-to-object type with designated type D1 and the actual type is an anonymous access-to-object type with designated type D2, then D1 shall cover D2, and the name or expression shall denote a view with an accessibility level for which the statically deeper relationship applies; in particular it shall not denote an access parameter nor a stand-alone access object. 28 A complete context shall have at least one acceptable interpretation; if there is exactly one, then that one is chosen. 29 There is a preference for the primitive operators (and ranges) of the root numeric types root_integer and root_real. In particular, if two acceptable interpretations of a constituent of a complete context differ only in that one is for a primitive operator (or range) of the type root_integer or root_real, and the other is not, the interpretation using the primitive operator (or range) of the root numeric type is preferred. 29.1/3 Similarly, there is a preference for the equality operators of the universal_access type (see 4.5.2). If two acceptable interpretations of a constituent of a complete context differ only in that one is for an equality operator of the universal_access type, and the other is not, the interpretation using the equality operator of the universal_access type is preferred. 30 For a complete context, if there is exactly one overall acceptable interpretation where each constituent's interpretation is the same as or preferred (in the above sense) over those in all other overall acceptable interpretations, then that one overall acceptable interpretation is chosen. Otherwise, the complete context is ambiguous. 31 A complete context other than a pragma_argument_association shall not be ambiguous. 32 A complete context that is a pragma_argument_association is allowed to be ambiguous (unless otherwise specified for the particular pragma), but only if every acceptable interpretation of the pragma argument is as a name that statically denotes a callable entity. Such a name denotes all of the declarations determined by its interpretations, and all of the views declared by these declarations. NOTES 33 17 If a usage name has only one acceptable interpretation, then it denotes the corresponding entity. However, this does not mean that the usage name is necessarily legal since other requirements exist which are not considered for overload resolution; for example, the fact that an expression is static, whether an object is constant, mode and subtype conformance rules, freezing rules, order of elaboration, and so on. 34 Similarly, subtypes are not considered for overload resolution (the violation of a constraint does not make a program illegal but raises an exception during program execution).