Version 1.2 of ais/ai-00312.txt

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

!standard 10.1.6 (05)          04-02-25 AI95-00312/01
!standard 4.1.3 (04)
!class binding interpretation 02-09-26
!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
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.
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.)
(See 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.)
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.
!ACATS test
Create a test to check that the above cases are allowed.

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

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:

    package parent is
    end parent;

    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