CVS difference for ai12s/ai12-0294-1.txt
--- ai12s/ai12-0294-1.txt 2018/12/07 07:00:34 1.5
+++ ai12s/ai12-0294-1.txt 2018/12/14 08:31:31 1.6
@@ -1,12 +1,13 @@
-!standard 3.3(23/3) 18-12-06 AI12-0294-1/03
+!standard 3.3(23/3) 18-12-10 AI12-0294-1/04
!class Amendment 18-11-15
!status Amendment 1-2012 18-11-15
+!status ARG Approved 8-0-3 18-10-21
!status work item 18-11-15
!status received 18-10-21
@@ -63,7 +64,7 @@
Nonblocking in generic units from the check. Therefore, an assume-the-worst
rule is needed in generic bodies to prevent the impossible case from happening.
-(5) One of the new Legality Rules added by AI12-0267-1 [9.10.1(6/5)] reads:
+(5) One of the new Legality Rules added by AI12-0267-1 [9.10.1(8/5)] reads:
If multiple Conflict_Check_Policy pragmas apply to a given construct, the
conflict check policy is determined by the one in the innermost enclosing
@@ -82,7 +83,8 @@
(1) Add after 5.5.3(20/5) [from AI12-0189-1]:
The sequence_of_statements of a loop_statement with a procedural_iterator as
-its iteration_scheme shall not contain an accept_statement.
+its iteration_scheme shall not contain an accept_statement whose
+entry_declaration occurs outside the loop_statement.
AARM Reason: An accept_statement is not allowed in a procedure (see 9.5.2),
it has to be directly in a task_body. Since the loop body here is implemented
@@ -183,11 +185,15 @@
In addition to the places where Legality Rules normally apply (see 12.3),
these rules also apply in the private part of an instance of a generic unit.
-(5) Replace the second sentence of 9.10.1(6/5) with:
+(5) Replace the second sentence of 9.10.1(8/5) with:
If no Conflict_Check_Policy pragma applies to a construct, the policy
is Parallel_Conflict_Checks (see below).
+ AARM To Be Honest: The region mentioned in this rule is the region to which
+ the policy pragma applies, and not the declarative region in which the policy
+ pragma appears. This distinction matters when there are multiple policy
+ pragmas in a single declarative region.
@@ -257,7 +263,7 @@
rechecked, and thus a dangerous subprogram could be declared and used.
The only way to prevent this problem is to reject Proc3 assuming that some
-instance will have Munge'Nomblocking evaluate to True. This should not present
+instance will have Munge'Nonblocking evaluate to True. This should not present
a problem in practice, since if a declaration like Proc3 is required, it can
always be moved to the private part (like Proc2), where it will be legal and
be rechecked as needed. A second workaround would be to give the declaration of
@@ -267,6 +273,13 @@
cases where there is no pragma that applies. Then the paragraph describes
all of the cases other than the obvious one where exactly one pragma applies.
+The intent of these rules is that the scoping works similarly to that of
+checking pragmas (Suppress/Unsuppress). So "region" is the region of
+application of the pragma, and not the declarative region in which the
+pragma appears. We add a To Be Honest note to clarify in case anyone would
+imagine something else.
@@ -391,7 +404,8 @@
The @fa<sequence_of_statements> of a @fa<loop_statement> with a
@fa<procedural_iterator> as its @fa<iteration_scheme> shall not contain
+an @fa<accept_statement> whose @fa<entry_declaration> occurs outside the
!comment The following is mainly to force a conflict.
Questions? Ask the ACAA Technical Agent