!standard 7.6(9.4/2) 07-10-25 AI05-0013-1/06 !standard D.7(4/2) !class binding interpretation 06-04-10 !status work item 06-05-29 !status ARG Approved 11-0-1 06-11-18 !status work item 06-04-10 !status received 06-04-03 !priority Medium !difficulty Medium !qualifier Error !subject No_Nested_Finalization is difficult to enforce !summary (See recommendation.) !question 7.6(9.4) says that "A type is said to need finalization if ... it is a limited type that has an access discriminant whose designated type needs finalization." This rule was intended to support coextensions, which get finalized when the parent object gets finalized, and must therefore have been taken into account for computing the "needs finalization" properties. However: (1) Coextensions can exist for nonlimited types. Thus, the "limited" should be deleted from the wording. (2) This property cannot be computed at the freezing point of the type (which is the natural place to do so), as the designated type may not be frozen yet. Indeed, there is no place during the current compilation where it can be computed if the designated type is an incomplete one from a limited view - it will not be known until link-time if the complete type is controlled. This definition is used in No_Nested_Finalization; (2) implies link-time checking. Such checking would be very expensive to build, because every nested use of a type with an access discriminant would have to be recorded, along with its definition, and checks would have to be made if the actual complete type does in fact "need finalization". Is this intended? (No.) !recommendation Change the No_Nested_Finalization check to disallow allocators of nested access types which designate types that need finalization, and delete the coextension rule from the definition of "needs finalization". !wording Delete 7.6(9.4/2). Replace D.7(3-10/2) with: No_Task_Hierarchy All (nonenvironment) tasks shall depend directly on the environment task of the partition. No_Nested_Finalization Objects of a type that needs finalization (see 7.6) shall be declared only at library level. There shall be no allocators for an access type whose designated type needs finalization if the access type does not have library-level accessibility. No_Abort_Statements There shall be no abort_statements, and there shall be no calls on Task_Identification.Abort_Task. No_Terminate_Alternatives There shall be no selective_accepts with terminate_alternatives. No_Task_Allocators There shall be no allocators for task types or types containing task subcomponents. No_Implicit_Heap_Allocations There shall be no operations that implicitly require heap storage allocation to be performed by the implementation. It is implementation defined which operations implicitly require heap storage allocation. No_Dynamic_Priorities There shall be no semantic dependences on the package Dynamic_Priorities, and no occurrences of the attribute Priority. No_Dynamic_Attachment There shall be no call to any of the operations defined in package Interrupts (Is_Reserved, Is_Attached, Current_Handler, Attach_Handler, Exchange_Handler, Detach_Handler, and Reference). Replace D.7(10.3/2-10.7/2) with: No_Protected_Type_Allocators There shall be no allocators for protected types or types containing protected type subcomponents. No_Relative_Delay There shall be no delay_relative_statements. No_Requeue_Statements There shall be no requeue_statements. No_Select_Statements There shall be no select_statements. No_Specific_Termination_Handlers There shall be no calls to the Set_Specific_Handler and Specific_Handler subprograms in Task_Termination. !discussion Directly attempting to fix problem (2) leads into a rat-hole of bad or incompatible solutions. (If you are interested, version /01 of this AI contained an exhaustive list.) The key is to fix the uses of "needs finalization" to consider coextensions. There is only one use: restriction No_Nested_Finalization. The best way to do this for No_Nested_Finalization is to make the allocators, rather than the access types, illegal. At this point, the designated type must be frozen, so there is no problem knowing whether it "needs finalization". Note that the new rule uses the accessibility level of the access type of the allocator. This is needed to take coextensions into account; the accessibility level is determined by an extensive set of rules and we certainly don't want to duplicate those. During editorial review it was noted that the wording of D.7 is weird because it uses sometimes "shall" and sometimes "is". This is inconsistent, and furthermore the meaning of "is" is unclear because we don't know if it's describing a rule that the user must adhere to, or the semantics of the language, or what (D.7(3) is especially bad). So we are fixing the entire section. !corrigendum 7.6(9.4/2) @ddel @xbullet !corrigendum D.7(4/2) @drepl @xindent @dby @xindents for an access type whose designated type needs finalization if the access type does not have library-level accessibility.> !ACATS test An ACATS B-Test should be created to test these cases. !appendix From: Pascal Leroy Date: Monday, April 3, 2006 8:04 AM 7.6(9.4) says that "A type is said to need finalization if ... it is a limited type that has an access discriminant whose designated type needs finalization." This rule was intended to support coextensions, which get finalized when the parent object gets finalized, and must therefore been taken into account for computing the "needs finalization" properties. However, there are two problems with this wording: 1 - The word "limited" should be erased because coextensions can exist for nonlimited types in Ada 2005. 2 - There is a nasty interaction with the freezing rules. I'd like to be able to compute the "needs finalization" property at the freezing point of the type that has the access discriminant, but at this point the type designated by the access discriminant may not be frozen yet (heck, it may not even be complete if it comes from a limited view). Comments? ****************************************************************