CVS difference for ai12s/ai12-0345-1.txt
--- ai12s/ai12-0345-1.txt 2019/10/02 01:42:49 1.2
+++ ai12s/ai12-0345-1.txt 2020/01/14 04:56:53 1.3
@@ -1,6 +1,9 @@
-!standard 3.10.2(13.4/4) 19-09-30 AI12-0345-1/01
-!standard 13.11.4(21/3)
-!standard 13.11.4(31/3)
+!standard 3.10.2(5) 20-01-13 AI12-0345-1/02
+!standard 3.10.2(7/4)
+!standard 3.10.2(10.5/3)
+!standard 3.10.2(13.4/4)
+!standard 3.10.2(19.2/5)
+!standard 3.10.2(21)
!class binding interpretation 19-09-30
!status work item 19-09-30
!status received 19-09-17
@@ -32,24 +35,65 @@
!wording
-Replace 3.10.2(13.4/4) with:
+Modify 3.10.2 (5):
-The accessibility level of an explicitly aliased (see 6.1) formal parameter
-in a function body the same as any other formal parameter, except that it is
-defined to match the level of the master of the call when compared to the
-level of the return object of the function.
-
-AARM Reason: We make checks on the actual object for an explicitly aliased
-parameter of a function to ensure that it can be returned, so we define that
-no checks are ever needed in that case. For all other uses, it acts the same
-as any other parameter (that is, it is treated as local to the function).
-
-AARM Implementation Note: If the dynamic level of an explicitly aliased
-parameter is needed for some purpose, it is local to the function -- it is
-never necessary to pass in the actual level of the call for explicitly aliased
-parameters. Note that the matching defined here can be implemented by simply
-omitting any check in the case where one is matching an explicitly aliased
-parameter to the master of the call.
+ Each master, and each entity and view created by it, has an
+ accessibility level{; when two levels are defined to be the same, the
+ accessibility levels of the two associated entities are said to be
+ *tied* to each other}:
+
+Modify 3.10.2 (7/4):
+
+ An entity or view defined by a declaration and created as part of its
+ elaboration has the same accessibility level as the innermost master
+ of the declaration except in the cases of renaming and derived access
+ types described below. [Other than for an explicitly aliased parameter
+ of a function or generic function, a]{A} formal parameter of a callable
+ entity has the same accessibility level as the master representing
+ the invocation of the entity.
+
+Delete AARM 3.10.2(10.d.6/3):
+ - when the function has an explicitly aliased parameter.
+
+Modify 3.10.2(10.5/3):
+ If the call itself defines the result of a function to which one of the
+ above rules applies,{ or has an accessibility level that is tied to the
+ result of such a function,} these rules are applied recursively;
+
+Delete 3.10.2(13.4/4):
+ The accessibility level of an explicitly aliased (see 6.1) formal
+ parameter in a function body is determined by the point of call; it
+ is the same level that the return object ultimately will have.
+
+Delete 3.10.2(19.2/5):
+ Inside a return statement that applies to a function or generic function F,
+ or inside the return expression of an expression function F, when
+ determining whether the accessibility level of an explicitly aliased
+ parameter of F is statically deeper than the level of the return object of
+ F, the level of the return object is considered to be the same as that of
+ the level of the explicitly aliased parameter; for statically comparing
+ with the level of other entities, an explicitly aliased parameter of F is
+ considered to have the accessibility level of a parameter of F that is
+ not explicitly aliased the body of F.
+
+Delete AARM 3.10.2(19.b/3):
+ To be honest: This rule has no effect if the previous bullet also applies
+ (that is, the “a level” is of an explicitly aliased parameter).
+
+Add after 3.10.2(21):
+
+Notwithstanding other rules given above, the accessibility level of an entity
+that is tied to that of an explicitly aliased formal parameter of an enclosing
+function is considered (both statically and dynamically) to be the same as
+that of an entity whose accessibility level is tied to that of the return object
+of that function.
+
+AARM Ramification: This rule only applies when the level of an explicitly
+aliased parameter of a function is compared to that of the return object of
+the function. If a value designating the explicitly aliased parameter is
+created and stored in a stand-alone object or passed as a parameter, this
+special property is lost (even for the dynamic accessibility of anonymous
+access types in these contexts).
!discussion
@@ -72,29 +116,90 @@
accessibility of an explicitly aliased parameter, and thus it would need to be
passed.
-Therefore, we reword the dynamic accessibility of explicitly aliased parameters
-to match the intended model exactly.
+---
+
+After a number of unsuccessful rewordings, we settled on the notion of two
+accessibility levels being "tied". When two tied levels are compared, the check
+always must pass (and a compiler should generate no check).
+
+The model is that this is ONLY true when tied levels are known at compile-time
+to be compared. In particular, storing an access value derived from an
+explicitly aliased parameter in a stand-alone object of an anonymous access
+type, or passing such a value as an access parameter, loses the "tied"
+property. In such cases, the dynamic accessibility of the parameter is local.
---
+
+Here are some examples to show some of the implications of these rules:
+
+ type Rec is record
+ Comp : aliased Integer;
+ ...
+ end record;
+ Glob : Boolean := ...;
+
+ function F1 (A : aliased in out Rec) return access Integer is
+ C : aliased Integer;
+ function F2 (B : access Integer) return access Integer
+ is (B); -- (1)
+ begin
+ if Glob then
+ return F2 (C'Access); -- Program_Error raised.
+ else
+ return F2 (A.Comp'Access); -- Program_Error raised.
+ end if;
+ end F1;
+
+The dynamic accessibility check at (1) should fail for either parameter
+passed to function F2. Even though the calls to F2 have the master of the
+call of F1, the special "tied to an explicitly aliased parameter" property
+is lost when the A.Comp'Access value is passed as a parameter.
+
+Contrast this to the similar case using explicitly aliased parameters:
+
+ function F4 (A : aliased in out Rec) return access Integer is
+ C : aliased Integer;
+ function F5 (B : aliased in out Integer) return access Integer
+ is (B'Access); -- (2)
+ begin
+ if Glob then
+ return F5 (C); -- Illegal.
+ else
+ return F5 (A.Comp); -- OK.
+ end if;
+ end F4;
+
+Here, (2) is both statically and dynamically checking "tied" accessibility
+levels, so no check of either kind is needed at (2). That works in part as
+such checks are moved to the call site of F5. Thus, passing the local object
+C is illegal, the static accessibility check on explicitly aliased parameters
+fails here. OTOH, the static check for A.Comp succeeds by definition, as it
+is comparing "tied" levels.
+
+---
+
+The change to 3.10.2(10.5/3) is intended to handle cases were some part of the
+return value is returned. For instance:
-An alternative model was proposed where the dynamic accessibility of an
-explicitly aliased parameter would be that of the return object, if the
-implementation would have to pass the level along with a call. This model
-would also have no additional cost, but it would have a maintenance hazard,
-as the accessibility of the parameter could change if the return type is
-changed (possibly even if only the private components of some hidden part
-of the return type is changed). This could cause working code to suddenly
-start raising Program_Error rather mysteriously.
-
-[Author's note: Steve's proposal makes large changes to the accessibility
-model for explicitly aliased parameters. That seems dangerous, accessibility
-is confusing enough without changing wording that we have some (small? :-)
-level of confidence in. I'd prefer to change as little as possible, especially
-as the intent was that no one could ever see the (real) dynamic accessibility
-level of an explicitly aliased parameter.
+ function F7 (A : aliased in out Rec) return access Integer is
+ C : aliased Rec := ...;
+ function F8 (B : aliased in out Rec) return access Rec
+ is (B'Access);
+ begin
+ if Glob then
+ return F8 (C).Comp'Access; -- Illegal.
+ else
+ return F8 (A).Comp'Access; -- OK.
+ end if;
+ end F7;
+
+The accessibility of the calls to F8 are now that of F7. This makes the
+accessibility of the result sufficient to return from F7. It means that
+the static check on the parameter C fails as it is too nested for to be
+returned.
-Steve didn't provide any of the examples that caused this discussion (I have
-to assume there were some, so it's impossible to tell if the "easy"]
+The old rule did not apply to this case as it said "used as the return"; here
+only a part of the return is used, and that part comes via a dereference.
!ASIS
@@ -102,6 +207,8 @@
!ACATS test
+A B-Test containing the examples above might be useful, as well as a C-Test
+that the special level does not persist.
!appendix
Questions? Ask the ACAA Technical Agent