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

--- ai12s/ai12-0363-1.txt	2020/06/18 05:20:34	1.7
+++ ai12s/ai12-0363-1.txt	2020/07/11 01:24:56	1.8
@@ -1,5 +1,10 @@
 !standard 3.10.2(26/3)                                  20-06-15  AI12-0363-1/05
 !standard 9.10(1/5)
+!standard C.6(6.4/3)
+!standard C.6(6.10/3)
+!standard C.6(8.1/4)
+!standard C.6(12/5)
+!standard C.6(12.1/5)
 !standard C.6(13.3/5)
 !standard C.6(19.1/5)
 !class Amendment 20-02-05
@@ -91,14 +96,12 @@
 
 !wording
 
-Modify 3.10.2 (26/3):
+Add after AARM 3.10.2 (28.b/2):
 
-  * The view shall not be a subcomponent that depends on discriminants
-    of an object unless the object is known to be constrained{;
+  AARM Discussion: Additional restrictions exist in the specialized needs
+    annexes. For instance, C.6 includes additional restrictions on atomic
+    and volatile prefixes of the Access attribute.
 
-  * The view shall not be a nonatomic subcomponent of a full access object
-    (see C.6)}.
-
 Modify 9.10 (1/5):
 
   If two different objects, including nonoverlapping parts of the same
@@ -169,6 +172,18 @@
   shall be atomic. Corresponding rules apply to volatile objects{
   and to full access objects.}
 
+  {If a nonatomic subcomponent of a full access object is
+  passed as an actual parameter in a call then the formal parameter
+  shall allow pass by copy (and, at run time, the parameter shall be
+  passed by copy). A nonatomic subcomponent of a full
+  access object shall not be used as an actual for a generic formal of
+  mode in out. The prefix of an attribute_reference for an Access 
+  attribute shall not denote a nonatomic subcomponent of a full access 
+  object.}
+
+  [Editor's note: This second paragraph was moved from C.6(13.3/5) in
+  order to keep like rules together.]
+
 Replace C.6(12.1/5):
 
    If the Atomic, Atomic_Components, Volatile, Volatile_Components,
@@ -190,7 +205,6 @@
   atomic. A corresponding rule applies to volatile types and similarly 
   to full access types.
 
-
   If a type with volatile components is used as an actual for a generic
   formal array type, then the components of the formal type shall be
   volatile. Furthermore, if the actual type has atomic components and
@@ -212,18 +226,8 @@
     of the formal type are volatile, but the current rule has been in
     place since 2012, so we don't see the need to relax it at this
     point.]
-
-Modify C.6(13.3/5):
 
-  If a nonatomic subcomponent of [an atomic]{a full access} object is
-  passed as {an}[the] actual parameter in a call then the formal parameter
-  shall allow pass by copy (and, at run time, the parameter shall be
-  passed by copy). A nonatomic subcomponent of [an atomic]{a full
-  access} object shall not be used as an actual for a generic formal of
-  mode in out. [A nonatomic subcomponent of an atomic type shall not be
-  aliased. A nonatomic subcomponent of an atomic type or object shall
-  not have components that are specified to be independently
-  addressable.]
+Remove C.6(13.3/5) [it was moved after C.6(12/5)]
 
 Modify RM C.6(19.1/5):
 
@@ -300,6 +304,141 @@
 often that it didn't seem to end up in a logical sequence. Hopefully
 the new wording is a little clearer.
 
+
+!corrigendum 9.10(1/3)
+
+@drepl
+If two different objects, including nonoverlapping parts of the same object, 
+are @i<independently addressable>, they can be manipulated concurrently by two 
+different tasks without synchronization. Any two nonoverlapping objects are 
+independently addressable if either object is specified as independently 
+addressable (see C.6). Otherwise, two nonoverlapping objects are independently
+addressable except when they are both parts of a composite object for which a
+nonconfirming value is specified for any of the following representation 
+aspects: (record) Layout, Component_Size, Pack, Atomic, or Convention; in this
+case it is unspecified whether the parts are independently addressable.
+@dby
+If two different objects, including nonoverlapping parts of the same object, 
+are @i<independently addressable>, they can be manipulated concurrently by two 
+different logical threads of control without synchronization, unless both are 
+subcomponents of the same full access object, and either is nonatomic (see C.6).
+Any two nonoverlapping objects are 
+independently addressable if either object is specified as independently 
+addressable (see C.6). Otherwise, two nonoverlapping objects are independently
+addressable except when they are both parts of a composite object for which a
+nonconfirming value is specified for any of the following representation 
+aspects: (record) Layout, Component_Size, Pack, Atomic, or Convention; in this
+case it is unspecified whether the parts are independently addressable.
+
+!corrigendum C.6(6.4/3)
+
+@dinsa
+@xhang<@xterm<Volatile>The type of aspect Volatile is Boolean.>
+@dinst
+@xhang<@xterm<Full_Access_Only>The type of aspect Full_Access_Only is Boolean.>
+
+!corrigendum C.6(6.10/3)
+
+@drepl
+If any of these aspects are directly specified, the @fa<aspect_definition> shall be 
+a static expression. If not specified (including by inheritance), each of these
+aspects is False.
+@dby
+If any of these aspects are directly specified, the @fa<aspect_definition>
+shall be a static expression. If not specified for a type (including
+by inheritance), the Atomic, Atomic_Components, and Full_Access_Only aspects 
+are False. If any of these aspects
+are specified True for a type, then the corresponding aspect is True
+for all objects of the type. If the Atomic aspect is specified True,
+then the aspects Volatile, Independent, and Volatile_Component (if
+defined) are True; if the Atomic_Components aspect is specified True,
+then the aspects Volatile, Volatile_Components, and
+Independent_Components are True. If the Volatile aspect is specified
+True, then the Volatile_Components aspect (if defined) is True, and
+vice versa. When not determined by one of the other aspects, or for an
+object by its type, the Volatile, Volatile_Components, Independent,
+and Independent_Components aspects are False.
+
+!corrigendum C.6(8.1/4)
+
+@dinsa
+When True, the aspects Independent and Independent_Components @i<specify as
+independently addressable> the named object or component(s), or in the case of
+a type, all objects or components of that type. All atomic objects and aliased
+objects are considered to be specified as independently addressable.
+@dinst
+The Full_Access_Only aspect shall not be specified unless the
+associated type or object is volatile (or atomic). A @i<full access> type is
+any atomic type, or a volatile type for which the aspect Full_Access_Only is
+True. A @i<full access> object (including a component) is any atomic object, or
+a volatile object for which the aspect Full_Access_Only is True for the object 
+or its type. A Full_Access_Only aspect is illegal if any subcomponent of
+the object or type is a full access object or is of a generic formal type.
+
+!corrigendum C.6(12/3)
+
+@drepl
+If an atomic object is passed as a parameter, then the formal
+parameter shall either have an atomic type or allow pass by copy. If an
+atomic object is used
+as an actual for a generic formal object of mode @b<in out>, then the
+type of the generic formal object shall be atomic. If the @fa<prefix> of
+an @fa<attribute_reference> for an Access attribute denotes an atomic
+object (including a component), then the designated type of
+the resulting access type shall be atomic. If an atomic type is used as
+an actual for a generic formal derived type, then the ancestor of the
+formal type shall be atomic. Corresponding rules
+apply to volatile objects and types.
+@dby
+If an atomic object is passed as a parameter, then the formal
+parameter shall either have an atomic type or allow pass by copy. If
+an atomic object is used as an actual for a generic formal object of
+mode @b<in out>, then the type of the generic formal object shall be
+atomic. If the @fa<prefix> of an @fa<attribute_reference> for an Access
+attribute denotes an atomic object (including a component), then the
+designated type of the resulting access type shall be atomic.
+Corresponding rules apply to volatile objects and to full access 
+objects.
+
+If a nonatomic subcomponent of a full access object is passed as
+an actual parameter in a call then the formal parameter shall
+allow pass by copy (and, at run time, the parameter shall be passed by copy).
+A nonatomic subcomponent of a full access object shall not be
+used as an actual for a generic formal of mode @b<in out>.
+The @fa<prefix> of an @fa<attribute_reference> for an Access attribute shall 
+not denote a nonatomic subcomponent of a full access object.
+
+!corrigendum C.6(12.1/3)
+
+@drepl
+If a volatile type is used as an actual for a generic formal array
+type, then the element type of the formal type shall be volatile.
+@dby
+If the Atomic, Atomic_Components, Volatile, Volatile_Components,
+Independent, Independent_Components, or Full_Access_Only aspect is
+True for a generic formal type, then that aspect shall be True for the
+actual type. If an atomic type is used as an actual for a generic
+formal derived type, then the ancestor of the formal type shall be
+atomic. A corresponding rule applies to volatile types and similarly 
+to full access types.
+
+If a type with volatile components is used as an actual for a generic
+formal array type, then the components of the formal type shall be
+volatile. Furthermore, if the actual type has atomic components and
+the formal array type has aliased components, then the
+components of the formal array type shall also be atomic. A corresponding 
+rule applies when the actual type has volatile full access components.
+
+!corrigendum C.6(19)
+
+@dinsa
+If an actual parameter is atomic or volatile, and the corresponding formal
+parameter is not, then the parameter is passed by copy. 
+@dinst
+All reads of or writes to any nonatomic subcomponent of a full access object
+are performed by reading and/or writing all of the nearest
+enclosing full access object.
+
 !ASIS
 
 No changes needed.
@@ -1399,5 +1538,63 @@
 
    A corresponding rule applies when the actual type has volatile full access
    components.
+
+****************************************************************
+
+A summary of a private thread which led to a number of editorial changes
+to this AI:
+
+July 9th, Randy:
+
+Answering my own question, C.6(13.3/5) covers that. (Aliased parameters do 
+not "allow pass-by-copy"). It is so far away from the main set of parameter 
+passing rules in C.6(12/5) that I thought it was part of the Dynamic Semantics
+when I looked at the AI earlier.
+
+It would be better to get these things closer together, but I think we'll need 
+to see the whole section of wording for C.6 to decide that (the AI context 
+isn't great for answering whether the rules should be organized differently). 
+Coming soon...
+
+July 10th, Randy:
+
+I think C.6(13.3) should go after C.6(12). With the removal of those last two 
+sentences, 13.3 is about parameter passing (subprogram and generic), and 12 is 
+about that as well. There is no definitions between those paragraphs. So why 
+shouldn't they be together?
+
+What do you think? I can do it before issuing the RM.
+
+Note that 13.3 is new in Ada 202x, so nothing requires it to be there.
+
+July 10th, Tucker:
+
+Seems fine.
+
+If we wanted to group all of these rules together, it would seem the new rule 
+in 3.10.2 (26) could be copied or moved to C.6, since paragraph (12) already 
+has a rule relating to the legality of 'Access.  It could be added to the end 
+of (13.3) (which you have proposed moving to follow immediately after (12)), 
+phrased as follows:
+
+  The prefix of an attribute_reference for an Access attribute shall not denote
+  a nonatomic subcomponent of a full access object.
+
+Could be marked as [Redundant:...] if we want to keep the one in 3.10.2, though 
+leaving it in 3.10.2 argues for having the other rule about 'Access from C.6(12)
+there as well.   Decisions, decisions...
+
+July 10th, Randy:
+
+I've always been uncomfortable with having an Annex rule in the core language, 
+and now I see that we were careful not to do that in the old rules. So I think 
+we should move the whole thing into C.6(13.3/5), which would be moved directly 
+after C.6(12/5). [The two following paragraphs are also new, so changing their 
+numbers doesn't matter.]
+
+Then 3.10.2(26) would be unchanged. Maybe an AARM note there about additional 
+restrictions found in the annexes, for example in C.6?
+
+I'll do this as my Editorial Review unless someone yells loudly not to.
 
 ****************************************************************