CVS difference for ai05s/ai05-0077-1.txt
--- ai05s/ai05-0077-1.txt 2007/12/07 05:17:06 1.1
+++ ai05s/ai05-0077-1.txt 2007/12/08 04:42:48 1.2
@@ -1,96 +1,372 @@
-!standard 13.9(7) 07-12-06 AI05-0070-1/01
-!class binding interpretation 07-12-06
-!status work item 07-12-06
-!status received 07-11-15
-!priority Low
+!standard 10.1.2(22/2) 07-12-07 AI05-0078-1/01
+!class binding interpretation 07-12-07
+!status work item 07-12-07
+!status received 07-12-05
+!priority Medium
!difficulty Easy
-!qualifier Clarification
-!subject Alignment need not match for Unchecked_Conversion
+!qualifier Error
+!subject The scope of a declaration does not include any context_clause
!summary
-The alignment of the source object of an unchecked conversion need only
-be a multiple of that of the target type for unchecked conversion to have
-a defined result.
+A limited_with_clause for a package P shall not appear in a context_clause
+that appears on a child unit that is within the scope of a non_limited_with_clause
+that mentions P or a use_clause that names an entity declared in P.
!question
-13.9(7) specifies that it is required that the source object and target
-type have identical alignment for an unchecked type conversion to have
-an language-defined effect.
-
-The intent of this rule appears to be to restrict the cases
-where an unchecked conversion has a language-defined effect to
-situations where the source object representation is valid with respect
-to the target type's alignment (allowing the representation of the
-source object to be viewed as a correctly aligned representation
-of a value of the target type).
-
-This rule disallows cases which would still meet this intent.
-It would be sufficient for S'Alignment to be any multiple of
-Target'Alignment.
+The declarative region of any entity includes the declarations of any child
+units (8.1(9)) and a child unit is a library unit (10.1.1(1)). A
+library unit is declared by a library_item ( 10.1.1(9)), and library_item
+doesn't include the context_clause (10.1.1(3)). Thus, a context_clause is
+not part of any declarative region. (AARM 10.1.6(6.c) says this explicitly).
+
+However, both 10.1.2(21/2) and 10.1.2(22/2) say that a limited_with_clause
+shall not appear within the scope of an entity. Since the scope of an entity
+is defined in terms of its declarative region, it is impossible for a
+limited_with_clause (which must be in a context_clause) to ever be within
+the scope of anything. It's unlikely that was the intent of these two rules.
+What was meant?
-Should this clause be changed? (Yes.)
-
!recommendation
(See Summary.)
!wording
+
+Change 10.1.1(21/2) to:
+
+* within a context_clause for a library item which is within the
+ scope of a nonlimited_with_clause that mentions the same
+ library package; or
-Replace 13.9(7) with:
+AARM Ramification: This applies to nonlimited_with_clauses found in
+the same context_clause, as well as nonlimited_with_clauses found on
+parent units.
-S'Alignment is a multiple of Target'Alignment.
+Change 10.1.2(22/2) to:
+* within a context_clause for a library item which is within the
+ scope of a use_clause that names an entity declared in the
+ declarative region of the library package.
+
+AARM Ramification: This applies to use_clauses found in the same
+context_clause, as well as use_clauses found in (or on) parent units.
+
!discussion
+
+It is intentional that the declarative region of an entity does not include
+any context_clause. AARM 10.1.6(6.a-6.c) discuss the reasons for this. As such,
+changing the meaning of declarative region would be a very bad idea.
+
+Instead, we focus on the library item that is associated with the context_clause.
+If it is within the scope of an appropriate entity, then a limited_with_clause
+in the context_clause is illegal.
+
+Note that we could have said "library_unit_declaration" rather than "library item"
+in the wording, as limited_with_clauses are not allowed on bodies, renamings, or
+subunits. However, this seems more specific than necessary, is wordier than
+necessary, and could present a future maintenance hazard for the Standard.
-Implementations are allowed to support unchecked conversions with
-mismatched alignments even without this language change
-(implementation-defined surely includes working as expected).
-So this language change only provides a bit of additional portability.
-
-!corrigendum 13.9(7)
-
-@drepl
-@xbullet<S'Alignment = Target'Alignment.>
-@dby
-@xbullet<S'Alignment is a multiple of Target'Alignment.>
+--!corrigendum 10.1.2(21/2)
+--!corrigendum 10.1.2(22/2)
+
!ACATS Test
-This might be testable, but it is likely that this would work anyway.
+This is tested by existing ACATS objectives which test the intent, not that actual rules.
!appendix
-!topic 13.9(7) is unnecessarily restrictive
-!reference Ada 2005 RM 13.9(7)
-!from Thomas Quinot 2007-11-15
-!keywords unchecked conversion, alignment
+!topic Error in 10.1.2(22)
+!reference RM05 10.1.2(19,22), 8.4(6)
+!from Adam Beneschan 07-12-05
!discussion
+
+I believe that the rule in 10.1.2(22) is worded incorrectly.
+
+Starting with paragraph 19, this says:
+
+ A limited_with_clause that names a library package shall not
+ appear: ...
+
+ in the same context_clause as, or within the scope of, a use_clause
+ that names an entity declared within the declarative region of the
+ library package.
+
+8.4(6) says that the scopes of use_clauses do not include context
+clauses. Since a limited_with_clause appears only in a context
+clause, this would mean that a limited_with_clause cannot appear in
+the scope of any use_clause. Therefore, the wording "within the scope
+of" in 10.1.2(22) cannot be correct.
+
+Perhaps the phrase between the commas should be changed to something
+like "or in the context_clause of a compilation unit that is within
+the scope of".
+
+(However, I think 10.1.2(21), which is similarly worded, is OK since
+it seems that the scope of a with_clause does have to include context
+clauses, and that the scope of a with_clause on P includes context
+clauses on a child unit P.Q.)
+
+****************************************************************
+
+From: Adam Beneschan
+Sent: Wednesday, December 5, 2007 11:37 AM
+
+Earlier, I wrote:
+
+> I believe that the rule in 10.1.2(22) is worded incorrectly.
+>
+> Starting with paragraph 19, this says:
+>
+> A limited_with_clause that names a library package shall not
+> appear: ...
+>
+> in the same context_clause as, or within the scope of, a use_clause
+> that names an entity declared within the declarative region of the
+> library package.
+>
+> 8.4(6) says that the scopes of use_clauses do not include context
+> clauses. Since a limited_with_clause appears only in a context
+> clause, this would mean that a limited_with_clause cannot appear in
+> the scope of any use_clause. Therefore, the wording "within the scope
+> of" in 10.1.2(22) cannot be correct.
+>
+> Perhaps the phrase between the commas should be changed to something
+> like "or in the context_clause of a compilation unit that is within
+> the scope of".
+
+It's occurred to me that a little care may be needed in fixing this.
+Consider:
+
+ package Pak1 is
+ package Nested is
+ ...
+ end Nested;
+ end Pak1;
+
+ with Pak1;
+ package Pak2 is
+ package Rename_Pak1 renames Pak1;
+ end Pak2;
+
+ with Pak2;
+ package Pak3 is
+ ...
+ ...
+ private
+ use Pak2.Rename_Pak1.Nested;
+ end Pak3;
+
+ limited with Pak1; -- legal??
+ package Pak3.Child is
+ ...
+ private
+ ...
+ end Pak3.Child;
+
+What, exactly, is the scope of the "use Pak2.Rename_Pak1" clause?
+Obviously, the "limited with" itself is not in this scope. The
+entirety of Pak3.Child isn't in the scope, either, since the portion
+of text before the word "private" isn't in the scope.
+
+But it seems that the "limited with" should still be illegal, since a
+portion of Pak3.Child (i.e. the private part) is within the scope of
+the "use" clause---and the same visibility problems that 10.1.2(22)
+was intended to address would still exist within the private part if
+the "limited with" were allowed.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Wednesday, December 5, 2007 11:34 AM
+
+> 8.4(6) says that the scopes of use_clauses do not include context
+> clauses. Since a limited_with_clause appears only in a context
+> clause, this would mean that a limited_with_clause cannot appear in
+> the scope of any use_clause. Therefore, the wording "within the scope
+> of" in 10.1.2(22) cannot be correct.
+
+I don't think so.
+
+The case that we are interested in is not 8.4(6), it's 8.4(7). It's the
+case where the limited with appears on a child unit, but the parent unit
+has, in some declarative part, a use_clause that names the same package.
+
+I don't see any wording in 8.4(7) saying that the context_clause is excluded
+from the scope of such a use_clause.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Wednesday, December 5, 2007 12:06 PM
+
+> What, exactly, is the scope of the "use Pak2.Rename_Pak1" clause?
+> Obviously, the "limited with" itself is not in this scope.
-13.9(7) specifies that it is required that the source object and target
-type have identical alignment for an unchecked type conversion to have
-an RM-defined effect.
-
-As I understand this clause, the intent of the clause is to restrict
-the scope of 13.9(5) (case where an unchecked conversion has a
-language-defined effect) to situations where the source object
-representation is valid with respect to the target type's alignment
-(allowing the representation of the source object to be viewed as a
-correctly aligned representation of a value of the target type).
-
-With respect to this intent, the restriction stated in 13.9(7) is a
-sufficient, but not necessary, condition. It would be sufficient for
-S'Alignment to be any multiple of Target'Alignment. So, I am suggesting
-that this clause be changed to:
+You may be right, but there is nothing "obvious" here.
-13.9(7) S'Alignment is a multiple of Target'Alignment
+8.4(7) has: "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."
+
+The declarative region in question includes the declarations of any child
+units (8.1(9)) and a child unit is a library unit (10.1.1(1)). A
+library unit is declared by a library_item ( 10.1.1(9)), and library_item
+doesn't include the context_clause (10.1.1(3)). So according to this line
+of reasoning a context_clause is not part of any declarative region.
+
+But note that this has nothing to do with the last sentence of 8.4(6),
+which only applies to a use_clause appearing in a context_clause. In fact,
+this sentence would seem to be redundant.
+
+One way to fix this would be to say that the context_clause of a unit is
+actually part of its declarative region. This is what I had been assumed all
+along, before I looked at the details.
****************************************************************
+From: Edmond Schonberg
+Sent: Wednesday, December 5, 2007 12:58 PM
+
+> I don't see any wording in 8.4(7) saying that the context_clause is
+> excluded from the scope of such a use_clause.
+
+
+I agree, the wording in 10,1,2 (22) is correct.
+(By the way, GNAT rejects the proposed example, as desired).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, December 5, 2007 1:21 PM
+
+Beware of 10.1.6(6.b-6.d). This explicitly says
+that a context clause is not in any declarative
+region, and attempts to explain why.
+
+I think Adam is right that we need a different
+way of saying that a limited with clause is
+not legal in certain context clauses due
+to "enclosing" use clauses. Using "scope"
+doesn't work, at least not as scope is currently
+defined. 10.1.6 is all about special visibility
+rules in context clauses and friends, so this might
+be a place to find and/or define a term that we need.
+
+I suppose we could say in 10.1.2(22), "for the
+purposes of this rule, a limited with clause
+is 'within the scope of a use clause' if any
+part of the compilation unit is within the scope
+of the use clause" though that seems a bit
+bogus.
+
+In any case, I think we do have an inconsistency
+here. particularly given what 10.1.6(6.c) says.
+
+****************************************************************
+
From: Tucker Taft
-Sent: Thursday, November 15, 2007 7:25 AM
+Sent: Wednesday, December 5, 2007 1:35 PM
-Your suggestion makes good sense to me.
+I suppose using the "scope of a non-limited with clause" in
+10.1.2(21) has the same problem. Perhaps because
+of the rules in 10.1.6, it is irrelevant whether
+context clauses are considered to be within the scope
+of "enclosing" with/use clauses. We could define
+which context clauses we want to be in the scope of
+a with/use clause simply so we could use the terms
+in 10.1.2(21,22). Alternatively, we could use the
+somewhat more circuitous wording about "a context
+clause for a compilation unit any part of which
+is in the scope of a use/non-limited-with clause."
****************************************************************
+
+From: Adam Beneschan
+Sent: Wednesday, December 5, 2007 1:32 PM
+
+> The case that we are interested in is not 8.4(6), it's 8.4(7). It's the
+> case where the limited with appears on a child unit, but the parent unit
+> has, in some declarative part, a use_clause that names the same package.
+
+Why does the use_clause have to be in a declarative part? In my first
+post on this, I didn't say anything about where the use_clause
+appeared. Is there any reason why the problem addressed by 10.1.2(22)
+in this case:
+
+ package Pak1 is
+ package Nested is
+ ...
+ end Nested;
+ end Pak1;
+
+ with Pak1;
+ package Pak2 is
+ package Rename_Pak1 renames Pak1;
+ end Pak2;
+
+ with Pak2;
+ use Pak2.Rename_Pak1.Nested;
+ package Pak3 is
+ end Pak3;
+
+ limited with Pak1;
+ package Pak3.Child is
+ end Pak3.Child;
+
+is any different from the problem that would occur if the "use
+Pak2.Rename_Pak1.Nested" were moved down one line? I don't see it.
+
+Furthermore, I don't see any particular reason why the scope of a
+use_clause appearing in a declarative part should include context
+clauses while the scope of a use_clause appearing in a context_clause
+should not.
+
+Furthermore, I don't think context clauses are included anyway,
+because I don't think declarative regions include context clauses.
+Looking at 8.1, it appears that a declarative region is comprised of
+declarations or portions of declarations---but looking at 10.1.1(2-4),
+a context_clause is separate from a declaration, not part of it. That
+could be why the phrase "The scope does not include context_clauses
+themselves" appears in square brackets both in RM95 and RM05. (Tucker
+also pointed out that 10.1.6(6.c) in the AARM says this explicitly.)
+
+By the way, this affects my earlier statement about whether 10.1.2(21)
+is OK. If I'm right that a declarative region never contains context
+clauses, then 10.1.2(21) is wrong also.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Wednesday, December 5, 2007 1:41 PM
+
+> In any case, I think we do have an inconsistency
+> here. particularly given what 10.1.6(6.c) says.
+
+Agreed.
+
+> I suppose we could say in 10.1.2(22), "for the
+> purposes of this rule, a limited with clause
+> is 'within the scope of a use clause' if any
+> part of the compilation unit is within the scope
+> of the use clause" though that seems a bit
+> bogus.
+
+Yuck. I hate it when we have to say "for the purposes of...".
+
+Instead of "within the scope of a use_clause" we could say "within a
+context_clause for a library_unit_declaration which is within the
+scope of a use_clause". That would have the desired effect. It would
+also cover the situation where the use and the with are "within the
+same context_clause". So 10.1.1(22) would look like:
+
+o within a context_clause for a library_unit_declaration which is
+within the scope of a use_clause that names an entity declared in the
+declarative region of the library package.
+
+****************************************************************
+
Questions? Ask the ACAA Technical Agent