CVS difference for ai05s/ai05-0290-1.txt
--- ai05s/ai05-0290-1.txt 2012/03/17 07:10:42 1.6
+++ ai05s/ai05-0290-1.txt 2012/03/20 06:14:57 1.7
@@ -1,15 +1,17 @@
-!standard 2.8(3) 12-03-08 AI05-0290-1/06
+!standard 2.8(3) 12-03-19 AI05-0290-1/07
!standard 2.8(4)
!standard 3.2.4(0)
!standard 3.8.1(21)
+!standard 4.6(51/2)
+!standard 4.6(57)
!standard 4.9.1(4)
!standard 6.1.1(0)
!standard 7.3.2(0)
-!standard 11.4.2(5/2)
!standard 11.4.2(6/2)
!standard 11.4.2(7/2)
!standard 11.4.2(9/2)
!standard 11.4.2(10/2)
+!standard 11.4.2(16/2)
!standard 11.4.2(17/2)
!standard 11.4.2(18/2)
!standard 11.5(7.2/2)
@@ -58,7 +60,7 @@
example, this would cause invariant checks to be performed only
occasionally. The proposal is generally that the policy in effect
at the time of the aspect specification controls all its checks.
-A key distinction between supressing a check and ignoring an assertion
+A key distinction between suppressing a check and ignoring an assertion
(by specifying a policy of "Ignore") is that in the latter case, the
assertion expressions that are not evaluated because of the policy are
*not* assumed to be true.
@@ -74,100 +76,195 @@
pragma_argument_association ::=
[pragma_argument_identifier =>] name
| [pragma_argument_identifier =>] expression
-{ | [pragma_argument_aspect_mark =>] name
- | [pragma_argument_aspect_mark =>] expression }
+{ | pragma_argument_aspect_mark => name
+ | pragma_argument_aspect_mark => expression }
In a pragma, any pragma_argument_associations without a
pragma_argument_identifier {or pragma_argument_aspect_mark} shall
precede any associations with a pragma_argument_identifier {or
pragma_argument_aspect_mark}.
-
-------------
+
+Add after 3.2.4(6/3):
+
+Predicate checks are defined to be *enabled* or *disabled* for a given
+subtype as follows:
+ * If a subtype is declared by a type_declaration or subtype_declaration
+ that includes a predicate specification, then:
+ - if performing checks is required by the Static_Predicate assertion
+ policy (see 11.4.2) and the declaration includes a Static_Predicate
+ specification, then predicate checks are enabled for the subtype;
+ - if performing checks is required by the Dynamic_Predicate assertion
+ policy (see 11.4.2) and the declaration includes a Dynamic_Predicate
+ specification, then predicate checks are enabled for the subtype;
+ - otherwise, predicate checks are disabled for the subtype [redundant:
+ , regardless of whether predicate checking is enabled for any
+ other subtypes mentioned in the declaration];
+
+ * If a subtype is defined by a derived type declaration that does not
+ include a predicate specification, then predicate checks are enabled for
+ the subtype if and only if predicate checks are enabled for at least one
+ of the parent subtype and the progenitor subtypes;
+
+ * If a subtype is created by a subtype_indication other than in one of the
+ previous cases, then predicate checks are enabled for the subtype if and
+ only if predicate checks are enabled for the subtype denoted by the
+ subtype_mark;
-replace 3.2.4(22/33) with:
+ * Otherwise, predicate checks are disabled for the given subtype.
+ [AARM: In this case, no predicate specifications can apply to the subtype
+ and so it doesn't typically matter whether predicate checks are enabled.
+ This rule does make a difference, however, when determining whether
+ predicate checks are enabled for another type when this type is one of
+ multiple progenitors. See the "derived type declaration" wording above.]
-If predicate checks are enabled for a given subtype (see 11.4.2),
-then:
+Replace 3.2.4(22/3) with:
+If predicate checks are enabled for a given subtype, then:
+
+In 3.2.4(23/3), replace "check is made" by "check is performed" (three times).
+
-------------
-append after 3.8.1(21):
+Add after 3.8.1(21):
-If the value of the discriminant governing the variant is not covered by the
-discrete_choice_list of the variant then Constraint_Error is raised. This rule
-applies in turn to any further variant that is, itself, included in the
-component_list of the given variant. This check is performed when an
-object of a discriminated type is initialized by default.
-
-AARM note:
- Like the checks associated with a per-object constraint, this check
- is not performed during the elaboration of a subtype indication.
- This check can fail if the discriminant subtype
- has a Static_Predicate specified, it also has predicate checking
- disabled, and the discriminant governs a variant part which
- lacks a "when others" choice.
+When an object of a discriminated type T is initialized by default, Constraint_Error is raised
+if no discrete_choice_list of any variant of a variant_part of T covers the value of the
+discriminant that governs the variant_part. When a variant_part appears in the component_list
+of another variant V, this test is only applied if the value of the discriminant governing V
+is covered by the discrete_choice_list of V.
+
+AARM implementation note:
+ This is not a "check"; it cannot be suppressed. However, in most cases it is not
+ necessary to generate any code to raise this exception. A test is needed (and can
+ fail) in the case where the discriminant subtype has a Static_Predicate specified,
+ it also has predicate checking disabled, and the discriminant governs a
+ variant_part which lacks a "when others" choice.
+
+ The test also could fail for a static discriminant subtype with range checking
+ suppressed and the discriminant governs a variant_part which lacks a "when others"
+ choice. But execution is erroneous if a range check that would have failed is
+ suppressed (see 11.5), so an implementation does not have to generate code to check
+ this case. (An unchecked failed predicate does not cause erroneous execution, so the
+ test is required in that case.)
+
+ Like the checks associated with a per-object constraint, this test is not made
+ during the elaboration of a subtype_indication.
+End AARM Implementation Note.
-------------
-modify 4.6 51/3 to be:
+Replace 4.6(51/3) with:
After conversion of the value to the target type, if the target
subtype is constrained, a check is performed that the value satisfies
this constraint. If the target subtype excludes null, then a check is
-made that the value is not null. If predicate checks are enabled
-for the target subtype (see 11.4.2), the predicate of the target
-subtype is applied to the value and Assertions.Assertion_Error is
-raised if the result is False.
+performed that the value is not null. If predicate checks are enabled
+for the target subtype (see 3.2.4), a check is performed that the
+predicate of the target subtype is satisfied for the value.
-------------
+
+Modify 4.6(57/3):
+
+If an Accessibility_Check fails, Program_Error is raised. {If a predicate check fails,
+Assertions.Assertion_Error is raised.} Any other check associated with a conversion raises
+Constraint_Error if it fails.
-modify 4.9.1(10/3) to be:
- both subtypes are static, every value that obeys the predicate of S1
- also obeys the predicate of S2, and it is not the case that
+-------------
+
+Replace 4.9.1(10/3) with:
+ both subtypes are static, every value that satisfies the predicate of S1
+ also satisfies the predicate of S2, and it is not the case that
both types each have at least one applicable predicate specification,
- predicate checking is enabled (see 11.2) for S2, and predicate
- checking is not enabled for S1.
+ predicate checks are enabled (see 11.4.2) for S2, and predicate
+ checks are not enabled for S1.
-------------
+
+Replace 6.1.1(19/3) with:
+
+If performing checks is required by the Pre, Pre'Class, Post, or Post'Class
+assertion policies (see 11.4.2) in effect at the point of a corresponding aspect
+specification applicable to a given subprogram or entry, then the respective
+precondition or postcondition expressions are considered @i(enabled).
-modify 6.1.1. 19/3 to read
+AARM Note: If a class-wide precondition or postcondition expression is enabled, it
+remains enabled when inherited by an overriding subprogram, even if the policy in
+effect is Ignore for the inheriting subprogram.
-If required by the Pre, Pre'Class, Post, or Post'Class assertion
-policies (see 11.4.2) in effect at the point of a corresponding aspect
-specification applicable to a given subprogram or entry, then the
-checks for the respective preconditions or postconditions are @i(enabled)
-for that subprogram or entry.
+Replace 6.1.1(31/3) with:
+Upon a call of the subprogram or entry, after evaluating any actual parameters,
+precondition checks are performed as follows:
-Modify 6.1.1 31/3 to:
+Modify 6.1.1(32/3):
-Upon a call of the subprogram or entry, after evaluating any actual
-parameters, enabled checks for preconditions are performed as follows:
+The specific precondition check begins with the evaluation of the specific precondition
+expression that applies to the subprogram or entry{, if it is enabled}; if the expression
+evaluates to False, Assertions.Assertion_Error is raised{; if the expression is not enabled,
+the check succeeds}.
-Modify 6.1.1. 35/3, first sentence, to:
+Modify 6.1.1(33/3):
-Upon successful return from a call of the subprogram or entry, prior to
-copying back any by-copy in out or out parameters, any enabled checks
-for postconditions are performed.
+The class-wide precondition check begins with the evaluation of any {enabled} class-wide
+precondition expressions that apply to the subprogram or entry. If and only if all the
+class-wide precondition expressions evaluate to False, Assertions.Assertion_Error is raised.
+AARM Ramification: Class-wide precondition checks are performed for all appropriate calls,
+but only enabled precondition expressions are evaluated. Thus, the check would be trivial
+if no precondition expressions are enabled.
-delete 6.1.1 40/3
+Modify 6.1.1(35/3):
+
+[If the assertion policy in effect at the point of a subprogram or entry declaration is
+Check, then upon]{Upon} successful return from a call of the subprogram or entry, prior to
+copying back any by-copy in out or out parameters, the postcondition check is performed. This
+consists of the evaluation of [the]{any enabled} specific and class-wide postcondition expressions
+that apply to the subprogram or entry. If any of the postcondition expressions evaluate to False,
+then Assertions.Assertion_Error is raised. The postcondition expressions are evaluated in an
+arbitrary order, and if any postcondition expression evaluates to False, it is not specified
+whether any other postcondition expressions are evaluated. The postcondition check, and any
+constraint {or predicate} checks associated with [copying back] in out or out parameters
+are performed in an arbitrary order.
+
+Delete 6.1.1(40/3).
+
-------------
-Modify 7.3.2 9/3 to:
+Modify 7.3.2(9/3):
-If required by the Type_Invariant or Type_Invariant'Class assertion
-policies (see 11.4.2) in effect at the point of a corresponding aspect
-specification applicable to a type T, then an invariant check is
-@i(enabled) for the type, and the check is performed at the following
-places, on the specified object(s):
+If one or more invariant expressions apply to a type T[, and the assertion policy (see 11.4.2) at
+the point of the partial view declaration for T is Check,] then an invariant check is performed
+at the following places, on the specified object(s):
+
+Add before 7.3.2(21/3):
+
+If performing checks is required by the Invariant or Invariant'Class assertion policies (see 11.4.2)
+in effect at the point of corresponding aspect specification applicable to a given type, then the
+respective invariant expression is considered @i(enabled).
+
+AARM Note: If a class-wide invariant expression is enabled for a type, it remains enabled when inherited
+by descendants of that type, even if the policy in effect is Ignore for the inheriting type.
+
+Modify 7.3.2(21/3):
+
+The invariant check consists of the evaluation of each {enabled} invariant expression that applies
+to T, on each of the objects specified above. If any of these evaluate to False, Assertions.Assertion_Error
+is raised at the point of the object initialization, conversion, or call. If a given call requires more
+than one evaluation of an invariant expression, either for multiple objects of a single type or for
+multiple types with invariants, the evaluations are performed in an arbitrary order, and if one of them
+evaluates to False, it is not specified whether the others are evaluated. Any invariant check is performed
+prior to copying back any by-copy in out or out parameters. Invariant checks, any postcondition check, and
+any constraint or predicate checks associated with in out or out parameters are performed in an arbitrary
+order.
-Delete 7.3.2 23/3
+Delete 7.3.2(23/3).
-------------
-Replace 11.4.2, 5/2 - 7/2 by:
+Replace 11.4.2(5/2 - 7/2) with:
The form of a pragma Assertion_Policy is as follows:
@@ -175,19 +272,19 @@
pragma Assertion_Policy(@i(assertion)_aspect_mark => policy_identifier
{, @i(assertion)_aspect_mark => policy_identifier});
-Pragma Assertion_Policy is allowed only immediately within a
+A pragma Assertion_Policy is allowed only immediately within a
declarative_part, immediately within a package_specification, or as a
configuration pragma.
-----
-Replace 11.4.2, 9/2 and 9/2a by:
+Replace 11.4.2(9/2) with:
The @i(assertion)_aspect_mark of a pragma Assertion_Policy shall be one of
Assert, Static_Predicate, Dynamic_Predicate, Pre, Pre'Class, Post,
Post'Class, Type_Invariant, Type_Invariant'Class, or some
implementation defined aspect_mark. The policy_identifier shall be
-Ignore or Check or some implementation-defined identifier.
+either Check, Ignore, or some implementation-defined identifier.
[AARM:
Implementation defined: Implementation-defined policy_identifiers and
@@ -195,25 +292,25 @@
------
-Replace 11.4.2, 10/2 by:
+Replace 11.4.2(10/2) with:
-Pragma Assertion_Policy determines for each assertion aspect named in
-the argument associations whether assertions of the given aspect are to
+A pragma Assertion_Policy determines for each assertion aspect named in
+the pragma_argument_associations whether assertions of the given aspect are to
be enforced by a run-time check. The policy_identifier Check requires
that assertion expressions of the given aspect be checked that they
evaluate to True at the points specified for the given aspect; the
policy_identifier Ignore requires that the assertion expression not be
evaluated at these points, and the run-time checks not be performed.
-Note that for subtype predicate aspects (see 3.2.4), even when the
+@Redundant[Note that for subtype predicate aspects (see 3.2.4), even when the
applicable Assertion_Policy is Ignore, the predicate will still be
evaluated as part of membership tests and Valid attribute_references,
and if static, will still have an effect on loop iteration over the
-subtype, and the selection of case_alternatives and variant_alternatives.
+subtype, and the selection of case_alternatives and variant_alternatives.]
If no assertion_aspect_marks are specified in the pragma, the specified
policy applies to all assertion aspects.
-Pragma Assertion_Policy applies to the named assertion aspects in a
+A pragma Assertion_Policy applies to the named assertion aspects in a
specific region, and applies to all assertion expressions specified
in that region. A pragma
Assertion_Policy given in a declarative_part or immediately within a
@@ -228,7 +325,7 @@
AARM note: This means that an Assertion_Policy pragma that occurs in a
scope enclosing the declaration of a generic unit but not also enclosing
the declaration of a given instance of that generic unit will not apply to
-assertion expressions occuring within the given instance.
+assertion expressions occurring within the given instance.
If multiple Assertion_Policy pragmas apply to a given construct for a
given assertion aspect, the assertion policy is determined by the one in
@@ -236,48 +333,28 @@
policy for the assertion aspect. If no such Assertion_Policy pragma
exists, the policy is implementation defined.
-Predicate checks are defined to be enabled or disabled for a given
-subtype as follows:
- If a subtype is declared by a type_declaration or subtype_declaration
- that includes one or more predicate specifications, then
- - if the applicable assertion policy for at least one of the assertion
- expressions is Check, then predicate checks are enabled for the
- subtype;
- - otherwise, predicate checks are disabled for the subtype [redundant:
- , regardless of whether predicate checking is enabled for any
- other subtypes mentioned in the declaration].
+[AARM:
+Implementation defined: The default assertion policy.]
- Otherwise, if a subtype is defined by a derived type declaration
- then predicate checks are enabled for the subtype if and only if
- predicate checks are enabled for at least one of the parent subtype
- and the progenitor subtypes.
-
- Otherwise, if a subtype is created by a subtype_indication then
- predicate checks are enabled for the subtype if and only if
- predicate checks are enabled for the subtype denoted by the
- subtype_mark.
+----------
- Otherwise, predicates checks are disabled for the given subtype.
- [AARM: In this case, no predicate specifications can apply to the subtype
- and so it doesn't typically matter whether predicate checks are enabled.
- This rule does make a difference, however, when determining whether
- predicates checks are enabled for another type when this type is one of
- multiple progenitors. See the "at least one" wording above.]
+Modify 11.4.2(16/2):
+A compilation unit containing a {check for an assertion (including a }pragma
+Assert{)} has a semantic dependence on the Assertions library unit.
-[AARM:
-Implementation defined: The default assertion policy.]
+[Needed because all such checks raise Assertions.Assertion_Error.]
----------
-Delete 11.4.2., 17/2.
+Delete 11.4.2(17/2).
----------
-Change 11.4.2, 18/2 to:
+Replace 11.4.2(18/2) with:
-If required by the Assert assertion policy in effect at the place of
-the pragma Assert, the elaboration of the pragma consists of
+If performing checks is required by the Assert assertion policy in effect
+at the place of a pragma Assert, the elaboration of the pragma consists of
evaluating the boolean expression, and if the result is False,
evaluating the Message argument, if any, and raising the exception
Assertions.Assertion_Error, with a message if the Message argument is
@@ -285,31 +362,34 @@
----------
-<<< Note to Editor: 11.5 7.2/3, the inline part was deleted as part of
-these discussions.>>>
-shorten 11.5 7.2/3 to:
+Replace 11.5(7.2/3) with:
-If a checking pragma applies to a generic instantiation, then the
+If a checking pragma applies to a generic_instantiation, then the
checking pragma also applies to the entire instance.
-<<Note to Editor - "shorten", in this case, means "shorten and then
-append an AARM note">>
-
AARM note: This means that a Suppress pragma that occurs in a
scope enclosing the declaration of a generic unit but not also enclosing
the declaration of a given instance of that generic unit will not apply to
constructs within the given instance.
+[Note: The inline part of this rule was deleted as part of these discussions.]
+
------------
-modify 11.5 25 to:
+Replace 11.5(25) with:
All_Checks
Represents the union of all checks; suppressing All_Checks suppresses
-all checks. In addition, an implementation is allowed (but not
-required) to behave as if a pragma Assertion_Policy(Ignore) applies to
-any region to which pragma Suppress(All_Checks) applies.
+all checks other than those associated with assertions. In addition,
+an implementation is allowed (but not required) to behave as if a
+pragma Assertion_Policy(Ignore) applies to any region to which
+pragma Suppress(All_Checks) applies.
+
+AARM Discussion: We don't want to say that assertions are suppressed,
+because we don't want the potential failure of an assertion to cause
+erroneous execution (see below). Thus they are excluded from the suppression
+part of the above rule and then handled with an implicit Ignore policy.
!discussion
@@ -346,11 +426,12 @@
not subsumed under the pragmas Suppress and Unsuppress with
appropriate check names. For example, in verified code, the policy
Ignore for Assertions make sense without impacting the program semantics.
-(Supressing a range check on the other hand can lead to abnormal values.)
+(Suppressing a range check on the other hand can lead to abnormal values.)
The ARG felt the following capability to be very useful, but shied away
from extending the model so late in the production if the 2012 standard.
-Ada 2020 should consider this capability:
+Ada 2020 should consider this capability (AI12-0022-1 has been opened to
+do this):
Example: Imagine the following routine in GUI library:
@@ -423,9 +504,238 @@
We could require that a subtype declaration such as Zero_Sub fail a
runtime check, but this seemed similar to per-object constraint checking.
+
+!corrigendum 2.8(3)
+
+@drepl
+@xcode<@fa<pragma_argument_association ::=
+ [>@i<@ft<pragma_argument_>>@fa<identifier =@>] name
+| [>@i<@ft<pragma_argument_>>@fa<identifier =@>] expression>>
+@dby
+@xcode<@fa<pragma_argument_association ::=
+ [>@i<@ft<pragma_argument_>>@fa<identifier =@>] name
+| [>@i<@ft<pragma_argument_>>@fa<identifier =@>] expression
+| >@i<@ft<pragma_argument_>>@fa<aspect_mark =@> name
+| >@i<@ft<pragma_argument_>>@fa<aspect_mark =@> expression>>
+
+!corrigendum 2.8(4)
+
+@drepl
+@xindent<In a @fa<pragma>, any @fa<pragma_argument_association>s without a
+@i<pragma_argument_>@fa<identifier> shall precede any associations with a
+@i<pragma_argument_>@fa<identifier>.>
+@dby
+@xindent<In a @fa<pragma>, any @fa<pragma_argument_association>s without a
+@i<pragma_argument_>@fa<identifier> or @i<pragma_argument_>@fa<aspect_mark>
+shall precede any associations with a
+@i<pragma_argument_>@fa<identifier> or @i<pragma_argument_>@fa<aspect_mark>.>
+
+!corrigendum 3.2.4(0)
+
+@dinsc
+[A placeholder to cause a conflict; the real wording is found in the conflict
+file.]
+
+!corrigendum 3.8.1(21)
+
+@dinsa
+A record value contains the values of the components of a particular @fa<variant> only
+if the value of the discriminant governing the @fa<variant> is covered by the
+@fa<discrete_choice_list> of the @fa<variant>. This rule applies in turn to any further
+@fa<variant> that is, itself, included in the @fa<component_list> of the given @fa<variant>.
+@dinst
+When an object of a discriminated type @i<T> is initialized by default, Constraint_Error is
+raised if no @fa<discrete_choice_list> of any @fa<variant> of a @fa<variant_part> of @i<T>
+covers the value of the discriminant that governs the @fa<variant_part>. When a
+@fa<variant_part> appears in the @fa<component_list> of another @fa<variant> @i<V>, this
+test is only applied if the value of the discriminant governing @i<V>
+is covered by the @fa<discrete_choice_list> of @i<V>.
+
+!corrigendum 4.6(51/2)
+
+@drepl
+After conversion of the value to the target type, if the target subtype is
+constrained, a check is performed that the value satisfies this constraint.
+If the target subtype excludes null, then a check is
+made that the value is not null.
+@dby
+After conversion of the value to the target type, if the target subtype is
+constrained, a check is performed that the value satisfies this constraint.
+If the target subtype excludes null, then a check is
+made that the value is not null. If predicate checks are enabled
+for the target subtype (see 3.2.4), a check is performed that the
+predicate of the target subtype is satisfied for the value.
+
+!corrigendum 4.6(57)
+
+@drepl
+If an Accessibility_Check fails, Program_Error is raised. Any other check associated
+with a conversion raises Constraint_Error if it fails.
+@dby
+If an Accessibility_Check fails, Program_Error is raised. If a predicate check fails,
+Assertions.Assertion_Error is raised. Any other check associated with a conversion raises
+Constraint_Error if it fails.
+
+!corrigendum 4.9.1(4)
+
+@drepl
+A constraint is @i<statically compatible> with a scalar subtype if it statically
+matches the constraint of the subtype, or if both are static and the
+constraint is compatible with the subtype. A constraint is @i<statically
+compatible> with an access or composite subtype if it statically matches
+the constraint of the subtype, or if the subtype is unconstrained.
+One subtype is @i<statically compatible> with a second subtype if the
+constraint of the first is statically compatible with the second
+subtype.
+@dby
+[A placeholder to cause a conflict; the real wording is found in the conflict
+file.]
+
+!corrigendum 6.1.1(0)
+
+@dinsc
+[A placeholder to cause a conflict; the real wording is found in the conflict
+file.]
+
+!corrigendum 7.3.2(0)
+
+@dinsc
+[A placeholder to cause a conflict; the real wording is found in the conflict
+file.]
+
+!corrigendum 11.4.2(6/2)
+
+@drepl
+@xcode<@ft<@b<pragma> Assertion_Policy(@i<policy_>@fa<identifier>);>
+@dby
+@xcode<@ft<@b<pragma> Assertion_Policy(@i<policy_>@fa<identifier>);
+@b<pragma> Assertion_Policy(
+ @i<assertion_>@fa<aspect_mark> =@> @i<policy_>@fa<identifier>
+ {, @i>assertion_>@fa<aspect_mark> =@> @i<policy_>@fa<identifier>});>
+
+!corrigendum 11.4.2(7/2)
+
+@drepl
+A @fa<pragma> Assertion_Policy is a configuration pragma.
+@dby
+A @fa<pragma> Assertion_Policy is allowed only immediately within a
+@fa<declarative_part>, immediately within a @fa<package_specification>, or as a
+configuration pragma.
+
+!corrigendum 11.4.2(9/2)
+
+@drepl
+The @i<policy_>@fa<identifier> of a @fa<pragma> Assertion_Policy shall be either Check,
+Ignore, or an implementation-defined identifier.
+@dby
+The @i<assertion_>@fa<aspect_mark> of a @fa<pragma> Assertion_Policy shall be one of
+Assert, Static_Predicate, Dynamic_Predicate, Pre, Pre'Class, Post,
+Post'Class, Type_Invariant, Type_Invariant'Class, or some
+implementation defined @fa<aspect_mark>. The @i<policy_>@fa<identifier> shall be
+either Check, Ignore, or some implementation-defined @fa<identifier>.
+
+!corrigendum 11.4.2(10/2)
+
+@drepl
+A @fa<pragma> Assertion_Policy is a configuration pragma that specifies the assertion policy
+in effect for the compilation units to which it applies. Different policies may apply to
+different compilation units within the same partition. The default assertion policy
+is implementation-defined.
+@dby
+A @fa<pragma> Assertion_Policy determines for each assertion aspect named in
+the @fa<pragma_argument_association>s whether assertions of the given aspect are to
+be enforced by a run-time check. The @i<policy_>@fa<identifier> Check requires
+that assertion expressions of the given aspect be checked that they
+evaluate to True at the points specified for the given aspect; the
+@i<policy_>@fa<identifier> Ignore requires that the assertion expression not be
+evaluated at these points, and the run-time checks not be performed.
+Note that for subtype predicate aspects (see 3.2.4), even when the
+applicable Assertion_Policy is Ignore, the predicate will still be
+evaluated as part of membership tests and Valid @fa<attribute_reference>s,
+and if static, will still have an effect on loop iteration over the
+subtype, and the selection of @fa<case_statement_alternative>s and
+@fa<variant>s.
+
+If no @i<assertion_>@fa<aspect_mark>s are specified in the pragma, the specified
+policy applies to all assertion aspects.
+
+A @fa<pragma> Assertion_Policy applies to the named assertion aspects in a
+specific region, and applies to all assertion expressions specified
+in that region. A @fa<pragma>
+Assertion_Policy given in a @fa<declarative_part> or immediately within a
+@fa<package_specification> applies from the place of the pragma to the end of
+the innermost enclosing declarative region. The region for a @fa<pragma>
+Assertion_Policy given as a configuration pragma is the declarative
+region for the entire compilation unit (or units) to which it applies.
+
+If a @fa<pragma> Assertion_Policy applies to a @fa<generic_instantiation>, then
+the @fa<pragma> Assertion_Policy applies to the entire instance.
+
+If multiple Assertion_Policy pragmas apply to a given construct for a
+given assertion aspect, the assertion policy is determined by the one in
+the innermost enclosing region of a @fa<pragma> Assertion_Policy specifying a
+policy for the assertion aspect. If no such Assertion_Policy pragma
+exists, the policy is implementation defined.
+
+
+!corrigendum 11.4.2(16/2)
+
+@drepl
+A compilation unit containing a @fa<pragma> Assert has a semantic dependence on the Assertions
+library unit.
+@dby
+A compilation unit containing a check for an assertion (including a @fa<pragma> Assert) has a
+semantic dependence on the Assertions library unit.
+
+!corrignedum 11.4.2(17/2)
+
+@ddel
+The assertion policy that applies to a generic unit also applies to all its instances.
+
+!corrignedum 11.4.2(18/2)
+
+@drepl
+An assertion policy specifies how a @fa<pragma> Assert is interpreted by the implementation.
+If the assertion policy is Ignore at the point of a @fa<pragma> Assert, the pragma is ignored.
+If the assertion policy is Check at the point of a @fa<pragma> Assert, the elaboration of the
+pragma consists of evaluating the boolean expression, and if the result is False, evaluating
+the Message argument, if any, and raising the exception Assertions.Assertion_Error, with a message
+if the Message argument is provided.
+@dby
+If performing checks is required by the Assert assertion policy in effect at the place of
+a @fa<pragma> Assert, the elaboration of the pragma consists of
+evaluating the boolean expression, and if the result is False,
+evaluating the Message argument, if any, and raising the exception
+Assertions.Assertion_Error, with a message if the Message argument is provided.
+
+
+!corrigendum 11.5(7.2/2)
+
+@drepl
+If a checking pragma applies to a generic instantiation, then the checking
+pragma also applies to the instance. If a checking pragma applies to a call to
+a subprogram that has a @fa<pragma> Inline applied to it, then the checking
+pragma also applies to the inlined subprogram body.
+@dby
+If a checking pragma applies to a @fa<generic_instantiation>, then the checking
+pragma also applies to the entire instance.
+
+!corrigendum 11.5(25)
+
+@drepl
+@xhang<@xterm<All_Checks>
+Represents the union of all checks; suppressing All_Checks suppresses all checks.>
+@dby
+@xhang<@xterm<All_Checks>
+Represents the union of all checks; suppressing All_Checks suppresses all checks other
+than those associated with assertions. In addition, an implementation is allowed
+(but not required) to behave as if a pragma Assertion_Policy(Ignore) applies to
+any region to which pragma Suppress(All_Checks) applies.>
+
!ACATS Test
-Create an ACATS C-Test to test these changes.
+Create ACATS C-Tests to test these changes, specifically that Ignore really
+ignores the check and local Check policies override more global Ignore policies.
!ASIS
Questions? Ask the ACAA Technical Agent