Version 1.3 of ais/ai-00312.txt

Unformatted version of ais/ai-00312.txt version 1.3
Other versions for file ais/ai-00312.txt

!standard 10.1.6 (05)          04-11-30 AI95-00312/02
!standard 10.1.6 (02)
!standard 4.1.3 (04)
!class binding interpretation 02-09-26
!status Amendment 200Y 04-11-30
!status ARG Approved 6-0-1 04-11-21
!status work item 02-09-26
!status received 02-09-11
!qualifier Omission
!priority Low
!difficulty Easy
!subject Environment-level visibility rules and generic children
!summary
It is legal to name a generic child unit in a pragma in a context clause and in a pragma at the place of a compilation unit.
!question
The standard makes the following illegal:
generic package Parent is ... end Parent;
generic procedure Parent.P1; pragma Elaborate_Body (Parent.P1); -- Illegal?
The problem is that Parent.P1 cannot be used to denote the generic procedure. Parent.P1 is not a legal expanded name because Parent is a generic, not a package, thus 4.1.3(4) does not apply. Moreover, the "enclosing named construct" clause of 4.1.3(4) doesn't apply because the pragma is not enclosed by Parent.
This is surprising. Is this intended to be illegal? (No.)
!recommendation
(See wording.)
!wording
Move the last two sentences of 10.1.6(2) to a new paragraph at the end of 10.1.6 (following 10.1.6(5)) and revise the wording as follows:
Notwithstanding the rules of 4.1.3, an expanded name in a with_clause{, a pragma in a context_clause, or a pragma that appears at the place of a compilation unit} 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.)
!discussion
The use of expanded names for generic child units is unusual in that such names cannot follow the normal rules for expanded names defined in 4.1.3. Clause 10.1.6 already has a special dispensation for generic child unit names used in with clauses (see the second to last sentence of 10.1.6(2)). The problem is that these names should also haven been allowed within pragmas that occur outside of the declarative region of a generic child unit. This oversight is addressed by extending the "notwithstanding" rule of 10.1.6(2) to include pragmas that occur within context clauses and at the place of a compilation unit. No exception is needed for the case of use clauses within a context clause because the name given in a use clause must denote a package, and so a generic child unit name is not allowed there.
!corrigendum 10.1.6(2)
Replace the paragraph:
Within the parent_unit_name at the beginning of a library_item, and within a with_clause, the only declarations that are visible are those that are library_items of the environment, and the only declarations that are directly visible are those that are root library_items of the environment. {notwithstanding} 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.)]
by:
Within the parent_unit_name at the beginning of a library_item, and within a with_clause, the only declarations that are visible are those that are library_items of the environment, and the only declarations that are directly visible are those that are root library_items of the environment.
!corrigendum 10.1.6(5)
Insert after the paragraph:
Within a pragma that appears at the place of a compilation unit, the immediately preceding library_item and each of its ancestors is visible. The ancestor root library_item is directly visible.
the new paragraph:
Notwithstanding the rules of 4.1.3, an expanded name in a with_clause, a pragma in a context_clause, or a pragma that appears at the place of a compilation unit} 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.)
!ACATS test
Create a test to check that the above cases are allowed.
!appendix

!topic Environment-level visibility rules and generics
!reference RM95 10.1.6(5), 4.1.3(4)
!from Adam Beneschan 09-11-02
!discussion

It appears that the RM makes this illegal, although I'm sure this is
not intentional and appears to be a bug in the RM:

    generic
    package parent is
        ...
    end parent;

    generic
    procedure parent.p1;
    pragma Elaborate_Body (parent.p1);   -- illegal

The problem is that "parent.p1" cannot be used to denote the generic
procedure.  In a non-generic example:

    package parent_2 is
        ...
    end parent;

    procedure parent_2.p2;
    pragma Elaborate_Body (parent_2.p2);

the special visibility rule in 10.1.6(5) states that "parent_2" and
"p2" are both visible; and parent_2 is a valid prefix for an expanded
name, by 4.1.3(4), because it is a package.

However, in the original example, "parent.p1" is not a legal expanded
name because "parent" is a generic, not a package; and the "enclosing
named construct" clause of 4.1.3(4) doesn't apply because the pragma
does not appear to be enclosed by the "parent" construct by any
definition of "enclosing" that I can find.  (8.1 says that the
declarative region of "parent" includes the child unit parent.p1, but
it stops at the semicolon, just before the pragma.)  Thus, "parent.p1"
doesn't meet the definition of an expanded name given by 4.1.3(4) and
is thus illegal.

****************************************************************

Questions? Ask the ACAA Technical Agent