CVS difference for ai12s/ai12-0319-1.txt

Differences between 1.3 and version 1.4
Log of other versions for file ai12s/ai12-0319-1.txt

--- ai12s/ai12-0319-1.txt	2019/03/08 06:57:10	1.3
+++ ai12s/ai12-0319-1.txt	2019/03/12 03:49:28	1.4
@@ -1,10 +1,12 @@
-!standard 9.5(47/5)                                  19-03-06  AI12-0319-1/02
+!standard 9.5(47/5)                                  19-03-11  AI12-0319-1/03
 !standard 9.5(69/5)
 !standard 13.11(15)
 !standard 13.11(17)
 !standard 13.11(18/4)
 !standard 13.11.2(3/5)
 !class Amendment 19-02-22
+!status Amendment 1-2012 19-03-11
+!status ARG Approved 6-0-4  19-03-11
 !status work item 19-02-22
 !status received 19-02-22
 !priority Low
@@ -125,9 +127,9 @@
 
 If the nominal subtype of the name specified for Storage_Pool is nonblocking, 
 then the primitive Allocate, Deallocate, and Storage_Size subprograms of that 
-type shall be nonblocking. Additionally, if the pool that supports subpools 
-(see 13.11.4), the primitive Default_Subpool_for_Pool, Allocate_From_Subpool,
-and Deallocate_Subpool subprogram shall be nonblocking.
+type shall be nonblocking. Additionally, if the pool that is one that supports 
+subpools (see 13.11.4), the primitive Default_Subpool_for_Pool, 
+Allocate_From_Subpool, and Deallocate_Subpool subprogram shall be nonblocking.
 
 Add after 13.11(17):
 
@@ -155,7 +157,7 @@
 
 generic
    type Object(<>) is limited private;
-   type Name   is access  Object;
+   type Name is access Object;
 procedure Ada.Unchecked_Deallocation(X : in out Name)
    with Preelaborate, 
         Nonblocking => Object'Nonblocking and Name'Storage_Pool'Nonblocking, 
@@ -165,18 +167,19 @@
 
 Note that Nonblocking is not used for elementary types. The finalization
 of elementary types has no effect; assignment of elementary types is trivial;
-and default initialization is always of a static value (if at all). Thus, 
-these things are always nonblocking for elementary types.
+and default initialization is always of a static value (or uninitialized). 
+Thus, these things are always nonblocking for elementary types.
 
 We have to ignore Nonblocking for elementary subtypes as whether a subtype is 
-elementary is view-dependent (private type are always composite types); but
+elementary is view-dependent (private types are always composite types); but
 the aspect Nonblocking is type-related (so the private view and full view have
 the same value).
 
 We only need new rules in the case of checking generic bodies. In all other
 cases, we have rules about including implicit calls when checking Nonblocking,
 and that makes the needed checks (for all of default initialization, 
-controlled finalization, and storage pool usage). In a generic specification, 
+controlled finalization, controlled assignment, and storage pool usage via 
+allocators and the Storage_Size attribute). In a generic specification, 
 those checks are made by the legality recheck that occurs on instantiation 
 based on the properties of the actual types.
 
@@ -192,8 +195,7 @@
 
 !ASIS
 
-[Not sure. It seems like some new capabilities might be needed,
-but I didn't check - Editor.]
+None needed; only the definition and use of some properties have changed.
 
 !ACATS test
 
@@ -242,6 +244,104 @@
 written in Ada, and since that probably isn't in Ada anyway, probably no one 
 would have noticed it. But allowing blocking in a nonblocking subprogram is 
 bad in any case. Must fix.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 11, 2019  2:24 PM
+
+Steve asked how the assume-the-worst rule for Nonblocking works in a generic 
+body for the storage pool of a formal access type. I wasn't able to give an 
+immediate answer (other than an assurance that it was considered). Here's 
+the real answer:
+
+The intent is that the storage pool of a formal access type needs to be 
+reflected in the contract of the generic. For instance:
+
+   generic
+       type Element is private;
+       type Ptr is access Element;
+   package Gen
+       with Element'Nonblocking and Ptr'Storage_Pool'Nonblocking is
+
+       procedure Save_It (E : in Element);
+
+       ...
+   end Gen;
+
+   package body Gen is
+
+       procedure Save_It (E : in Element) is
+       begin
+	     ... new Element'(E); 
+       end Save_It;
+
+       ...
+
+   end Gen;
+
+Save_It inherits the Nonblocking contract from the enclosing unit, so it also 
+has a contract of Element'Nonblocking and Ptr'Storage_Pool'Nonblocking.
+
+The allocator makes implicit calls to Finalize of Element (which is covered by 
+Element'Nonblocking), and Allocate of the pool of Ptr (which is covered by 
+Ptr'Storage_Pool'Nonblocking), so all is well.
+
+The wording has always made it clear that implicit calls are handled the same 
+way as explicit calls. For the assume-the-worst rules, I have two To Be Honest
+notes which explain that the contract of Finalize (and Initialize [and default
+init] and Adjust) is type'Nonblocking, and the contract of Allocate (and 
+Storage_Size) is Ptr'Storage_Pool'Nonblocking. The assume-the-worst rules 
+require that either the contract of the enclosing subprogram is statically 
+False or that it contains the contract of any call that it contains. (Of 
+course, if the needed contract is itself static (that is, doesn't depend on a 
+formal type), then we just use the normal static check. See the rules for 
+details.)
+
+If Save_It had been declared
+
+     procedure Save_It (E : in Element) with Nonblocking;
+
+then the allocator makes the subprogram body illegal, because neither of the 
+conditions of the assume-the-worst rule are satisfied (the contract is not 
+statically False, and it does not contain Element'Nonblocking nor 
+Ptr'Storage_Pool'Nonblocking).
+
+So I'm pretty certain this is covered. There is a some handwaving about the 
+desired contract (we want to use the most specific one possible, but defining
+that precisely is difficult), but the rules do the right thing presuming you 
+have the contract.
+
+We probably will need some ACATS tests on this, and the containers will use 
+some of it as well, so I expect compilers will do the right thing eventually
+(might take a few iterations to get it right).
+
+P.S. There are similar issues surrounding Global in these same cases. It 
+definitely handles finalization properly, not sure about default 
+initialization, and it probably needs some fixes for pools. That's a separate 
+AI for some other time.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, March 11, 2019  2:51 PM
+
+> ...
+> 
+> The intent is that the storage pool of a formal access type needs to 
+> be reflected in the contract of the generic. For instance:
+> 
+>   generic
+>       type Element is private;
+>       type Ptr is access Element;
+>   package Gen
+>       with Element'Nonblocking and Ptr'Storage_Pool'Nonblocking is
+
+I suspect you mean:
+
+     with Nonblocking => Element'Nonblocking and Ptr'Storage_Pool'Nonblocking ...
+
+Otherwise, looks good.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent