CVS difference for ais/ai-00224.txt

--- ais/ai-00224.txt	2002/06/14 23:48:55	1.23
+++ ais/ai-00224.txt	2002/07/23 01:05:23	1.24
@@ -1,4 +1,4 @@
-!standard 11.5(1-8)                                  02-06-13  AI95-00224/05
+!standard 11.5(1-8)                                  02-07-12  AI95-00224/06
 !standard 11.5(27)
 !class amendment 99-11-19
 !status work item 99-11-19
@@ -46,10 +46,10 @@
 Define "Checking pragmas" and add pragma Suppress to 11.5(1)
 ("Checking pragmas" is in italics):
 
-Checking pragmas give an implementation instructions on handling
-language-defined checks. A pragma Suppress gives permission to an implementation
-to omit certain language-defined checks, while a pragma Unsuppress revokes the
-permission to omit checks.
+*Checking pragmas* give an implementation instructions on handling
+language-defined checks. A pragma Suppress gives permission to an
+implementation to omit certain language-defined checks, while a pragma
+Unsuppress revokes the permission to omit checks.
 
 Add pragma Unsuppress to 11.5(3-4), and remove the On parameter from Suppress:
 
@@ -77,14 +77,18 @@
 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 checking pragma given as a configuration pragma is the
-entire compilation unit to which it applies. It is implementation-defined
-if the pragma applies to compilation units other that those specified by
-the definition of configuration pragma (see 10.1.5).
-
-AARM Note: This means that a configuration checking pragma may automatically
-apply to bodies and subunits (as is true of other checking pragmas), but it
-does not have to.
+declarative region for the entire compilation unit to which it applies.
 
+[If a checking pragma applies to a generic instantiation or a call to a
+subprogram that has a pragma Inline applied to it, then the checking pragma
+also applies to the instance or subprogram body.]
+
+AARM Proof: An instance is copy of the generic at the place of the instantiation
+(see 12.3(12)); and inlined subprogram bodies are expanded at the place of the
+call (see 6.3.2). This rule just makes it clear that we meant that. Note that
+implementations are not required to suppress checks in these contexts, as this
+is a permission, not a requirement.
+
 A pragma Suppress gives permission to an implementation to omit the named check
 for any entities to which it applies. A pragma Unsuppress revokes the permission
 given by pragma Suppress to omit the named check for any entities to which it
@@ -214,9 +218,9 @@
 permission to omit" rather than "requiring" checks.
 
 Pragma Unsuppress is defined to affect checks suppressed by a pragma Suppress.
-This is necessary to support pragma Unchecked_Union (which is defined in
-terms of suppressing checks, and these checks cannot be turned on as there
-is no discriminant value with which to make a check).
+This is necessary to support pragma Unchecked_Union, which is defined in
+terms of suppressing checks. The checks for pragma Unchecked_Union cannot be
+turned on as there is no discriminant value with which to make a check.
 
 
 This proposal allows nested suppression of checks. That is, checks can be
@@ -235,9 +239,9 @@
 a pragma Suppress used in a package specification also applies to the package
 body, and a pragma Suppress also applies to any subunits in the declarative
 region. This inheritance is not commonly implemented by Ada 95 compilers. This
-is OK, as the permission to suppress checks can always be ignored. However, the
-situation for Unsuppress is different. If it fails to inherit properly, checks
-might be suppressed that should not be. This could badly break programs.
+is OK, as the permission to suppress checks can always be ignored. It appears
+that the situation for Unsuppress is different. If it fails to inherit
+properly, checks might be suppressed that should not be.
 
 We considered eliminating inheritance from all of these programs, as it is
 preferable that a checking pragma be visible in any scope to which it applies.
@@ -263,14 +267,63 @@
 and that it leaves the language no safer than the existing inheritance model.
 
 Therefore, we have retained the inheritance model of Ada 95, and it applies
-to pragma Unsuppress as well as Suppress.
-
-We do make the units to which a checking pragma given as a configuration
-pragma applies implementation-defined. This allows an implementation to
-support inheritance for these without requiring it. These pragmas are rarely
-used explicitly; they primarily are a semantic description of compiler options
-for suppression. We do not want to force implementations to have options apply
-to other compilations (such as subunits).
+to pragma Unsuppress as well as Suppress. The basic model is that a
+configuration checking pragma is equivalent to the same checking pragma
+given at the first possible place within the unit.
+
+With this model, inheritance of Unsuppress is not a problem, even for
+implementations that do not implement inheritance. Recall that the rule for
+Unsuppress is that it revokes the permission to omit checks that currently
+exist, and it has no effect on checks that are suppressed later. Now, consider:
+
+    package P is
+       pragma Unsuppress (Overflow_Check);
+       procedure Proc;
+    end P;
+
+    pragma Suppress (Overflow_Check); --(1)
+    package body P is
+       pragma Suppress (Overflow_Check); --(2)
+       procedure Proc is ...
+    end P;
+
+Pragma (2) clearly occurs after the pragma Unsuppress, so the Unsuppress has
+no effect, and the check is suppressed. By the equivalence model, pragma (1)
+is equivalent to pragma (1).
+
+It is important to note that pragma Unsuppress has no effect of its own. There
+only is a permission to omit checks or no permission to do. Essentially,
+an implementation which does not inherit the permission will always make the
+checks. This is identical to an implementation which does inherit the
+permission in the case when it is revoked (because then the checks are
+required). So, the only requirement is that an implementation inherit the
+permission or lack of one in the same way.
+
+It has been suggested that an implementation which did not inherit would have
+problems with generic instances and inlined subprograms. But this is not true.
+If the subprogram or generic contains an explicit Suppress, that pragma should
+be honored in any implementation. If the subprogram or generic inherits the
+permission to suppress, and it contains an appropriate pragma Unsuppress, the
+checks must be made. But this must happen, even if the implementation does not
+inherit the permission, as in that case the checks would have been made in
+any instance.
+
+The point of this discussion is that it is not necessary for implementations
+to change their inheritance semantics in order to implement Unsuppress.
+
+
+If more than one checking pragma is given as configuration pragmas, the
+language does not specify the order in which they are applied. This means that
+the exact effect is unspecified as well (as the order of the pragmas could
+change their effect). Consider:
+    pragma Suppress (All_Checks);
+    pragma Unsuppress (Storage_Check);
+vs.
+    pragma Unsuppress (Storage_Check);
+    pragma Suppress (All_Checks);
+Whether or not Storage_Check is suppress depends on the order of the pragmas.
+This doesn't seem to be an important enough problem to worry about; Unsuppress
+should be used in local scopes, not as a configuration pragma.
 
 
 Restrictions can be placed on pragma Unsuppress. This is necessary to avoid