CVS difference for ai05s/ai05-0290-1.txt
--- ai05s/ai05-0290-1.txt 2012/03/17 07:00:18 1.5
+++ ai05s/ai05-0290-1.txt 2012/03/17 07:10:42 1.6
@@ -1,6 +1,8 @@
-!standard 2.8(3) 12-02-28 AI05-0290-1/05
+!standard 2.8(3) 12-03-08 AI05-0290-1/06
!standard 2.8(4)
!standard 3.2.4(0)
+!standard 3.8.1(21)
+!standard 4.9.1(4)
!standard 6.1.1(0)
!standard 7.3.2(0)
!standard 11.4.2(5/2)
@@ -27,6 +29,13 @@
A perceived problem with Pragma Suppress for inlined calls is fixed.
+Variant parts now handle not-covered-by-any-choice selector values in
+the same way as case statements and case expressions.
+
+The definition of "statically compatible" for subtypes is improved so that
+a type with a disabled predicate check is not statically compatible with
+a type with an enabled predicate check.
+
!problem
When assertions (particularly predicates and preconditions) are used in
@@ -49,9 +58,10 @@
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.
-Subtype predicates use a somewhat different rule, but a key feature
-is that when the policy is "Ignore," the assertion expressions that are
-not evaluated because of the policy are *not* assumed to be true.
+A key distinction between supressing 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.
!proposal
@@ -74,79 +84,53 @@
-------------
+
+replace 3.2.4(22/33) with:
-modify 3.2.4(22/3-23/3) to be:
+If predicate checks are enabled for a given subtype (see 11.4.2),
+then:
-If required by the Static_Predicate or Dynamic_Predicate assertion
-policies (see 11.4.2) in effect at the point of the use of a
-subtype_mark that denotes a given subtype, the predicate check is
-@i(enabled) for the subtype of the entity or expression to which the
-subtype_mark applies.
-
- AARM Discussion: The Assertion_Policy for subtype predicate aspects is
- relevant at the following places where a subtype_mark can occur: alone
- or as part of a subtype_indication that is defining the subtype of an
- object (including a formal parameter, a function result, or a generic
- formal object of mode IN), a component (including a discriminant), a
- designated object, the parent of a derived type or the ancestor_part
- of an extension_aggregate, and in an explicit type_conversion or
- qualified_expression. In other contexts, the Assertion_Policy is not
- relevant, as no checks are directly tied to the predicate of the
- subtype named by the subtype_mark. In particular, when one subtype is
- defined in terms of another, the predicate of the precursor subtype is
- always carried over to the new subtype (and possibly augmented with
- another predicate expression), and the Assertion_Policy at that point
- is irrelevant. What matters is the policy at the point where the new
- subtype's subtype_mark is later used. This ensures that a
- subtype_declaration that is merely used as a renaming, such as
- "subtype S is P.S;" has no direct impact on predicate checks. What
- matters is where S or P.S are used to define the subtype of an object,
- and the Assertion_Policy in effect at the point of that object's
- declaration.
-
- We use the point of declaration of the object rather than the point of
- delaration of the subtype because we want "subtype S is P.S;" to create
- a true equivalence, and because we don't want to deal with "partial"
- predicates, where some of the predicate checks of a subtype are enabled
- while some are not. We use the point of declaration of the object
- rather than the point of the check, because we want a given predicate
- to either apply completely or not at all to an object, to avoid
- erroneous execution due to the use of an incorrect predicate when
- the assertion policy is Ignore.
-
-
-[Redundant: On a subtype conversion where predicate checks are enabled
-for the target subtype, the predicate of the target subtype is
-evaluated, and a check is made that the predicate is True. If predicate
-checks are not enabled for the target subtype, the predicate is not
-evaluated. This includes subtype conversions as part of parameter
-passing, except for certain parameters passed by reference, which are
-covered by the following rule:] After normal completion and leaving of a
-subprogram, for each in out or out parameter that is passed by
-reference, if a predicate check is enabled for the subtype of the
-actual, the predicate of the subtype of the actual is evaluated, and a
-check is made that the predicate is True.
-
-If predicate checks are enabled for the nominal subtype of an object
-that is created by an object_declaration with no explicit initialization
-expression, by an uninitialized allocator, or by an ancestor_part of an
-extension_aggregate that is a subtype_mark, and one or more
-subcomponents have default_expressions, then the predicate of the
-nominal subtype is evaluated, and a check is made that it is True.
+-------------
+
+append after 3.8.1(21):
-Assertions.Assertion_Error is raised if any of the above predicate checks fail.
+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.
+-------------
+
modify 4.6 51/3 to be:
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, the predicate of the target subtype is applied to the
-value and Assertions.Assertion_Error is raised if the result is False.
+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.
-------------
+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
+ 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.
+
+-------------
+
modify 6.1.1. 19/3 to read
If required by the Pre, Pre'Class, Post, or Post'Class assertion
@@ -230,8 +214,8 @@
policy applies to all assertion aspects.
Pragma Assertion_Policy applies to the named assertion aspects in a
-specific region, and applies to all assertion expressions (or predicated
-subtype_marks -- see 3.2.4) specified in that region. A pragma
+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
package_specification applies from the place of the pragma to the end of
the innermost enclosing declarative region. The region for a pragma
@@ -241,13 +225,46 @@
If a pragma Assertion_Policy applies to a generic_instantiation, then
the pragma Assertion_Policy applies to the entire instance.
+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.
+
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 pragma Assertion_Policy specifying a
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].
+
+ 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.]
+
[AARM:
Implementation defined: The default assertion policy.]
@@ -275,6 +292,14 @@
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.
+
------------
modify 11.5 25 to:
@@ -298,8 +323,8 @@
the controlling policy.
For subtype predicates, the policy that is relevant is the one in effect
-at the point where the subtype_mark is used to define an object, or
-perform an explicit type_conversion or qualified_expression.
+at the point where the "nearest" applicable predicate specification
+is provided.
The Assertion_Policy pragma allows control over each assertion aspect
individually, if so desired. The need was clearly identified, e.g., to
@@ -368,6 +393,36 @@
is still a problem, because the decision to inline may be made after the
decision is made whether to insert or omit checks.
+----
+
+This example illustrates the motivation for the new 3.8.1 rule about
+variant parts:
+
+ declare
+ pragma Assertion_Policy (Ignore);
+
+ subtype Non_Zero is Integer with Static_Predicate
+ => Non_Zero /= 0;
+
+ type Rec (D : Non_Zero) is
+ record
+ case D is
+ when Integer'First .. -1 => ...;
+ when 1 .. Integer'Last => ....;
+ end case;
+ end record;
+
+ Zero : Integer := Ident_Int (0);
+
+ subtype Zero_Sub is Rec (D => Zero); -- no exception is raised here
+
+ X : Rec (D => Zero); -- raises Constraint_Error
+ begin
+ null;
+ end;
+
+We could require that a subtype declaration such as Zero_Sub fail a
+runtime check, but this seemed similar to per-object constraint checking.
!ACATS Test
Create an ACATS C-Test to test these changes.
Questions? Ask the ACAA Technical Agent