CVS difference for ais/ai-00224.txt

--- ais/ai-00224.txt	2000/03/23 23:24:04	1.15
+++ ais/ai-00224.txt	2000/03/27 18:17:34	1.16
@@ -3339,3 +3339,268 @@
 
 *************************************************************
 
+From: Tucker Taft
+Sent: Friday, March 24, 2000 6:33 AM
+
+Randy Brukardt wrote:
+>
+> I've posted a revised AI-224 on the ACAA web site (www.ada-auth.org/~acats)
+>
+
+I hate to restart this firestorm, but I believe you still don't adequately
+deal with configuration pragmas that apply to a particular source file.
+Are their effects inherited by bodies that are in different source files,
+if the spec is in a file that contains a config pragma?
+
+If so, and the body's file has one as well, does the body's config pragma
+supersede the spec's config pragma, but *not* supersede a pragma declared
+*inside* the package spec?  E.g., in this example, what is the order of precedence
+for the following 3 pragmas:
+
+    file 1:
+         pragma1;
+
+         package foo is
+             pragma2;
+             ...
+         end foo;
+
+    file 2:
+         pragma 3;
+
+         package body foo is
+              --- what is precedence order of pragmas?
+                   2 (highest), 1, 3
+                   2, 3, 1
+                   3,2,1
+                   3,2 (1 is irrelevant here)
+                   3 (1 and 2 are irrelevant here)
+                   other combos?
+
+            ...
+
+I would dearly like to know the answer to this, as well as the rationale for the answer.
+If it is already in the AI and I am too stupid to see it, could you point
+out where it is, and perhaps add an example like the above (with the answer) into the AI for
+stupid folks like me?  (There is discussion about declarative regions, but I don't
+feel comfortable trying to figure out the rules for config pragmas based solely on implicitly
+generalizing the notion of declarative region to include "file level" or "environment".)
+
+Also, be sure to mention the suppression inheritance rules, if any, from the context of a stub
+to the corresponding subunit (hopefully similar to spec/body inheritance) and how it interacts
+with config pragmas (hopefully analogously to spec/body rule).
+
+
+>
+>                                 Randy.
+
+Note that command-line switches might be considered roughly equivalent to config pragmas
+that apply to the sources being compiled.  But of course, command-line switch interpretation
+is most definitely implementation defined.  It might be worth mentioning them in the AI
+in any case (maybe you already do).
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 24, 2000 6:36 AM
+
+<<I hate to restart this firestorm, but I believe you still don't adequately
+deal with configuration pragmas that apply to a particular source file.
+Are their effects inherited by bodies that are in different source files,
+if the spec is in a file that contains a config pragma?
+>>
+
+Robert's answers (correspond to what GNAT does) are Yes to this
+
+If so, and the body's file has one as well, does the body's config pragma
+supersede the spec's config pragma, but *not* supersede a pragma declared
+*inside* the package spec?  E.g., in this example, what is the order of preceden
+ce
+for the following 3 pragmas:
+
+Yes and Yes
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Friday, March 24, 2000 8:47 AM
+
+Which is equivalent to saying that the pragma precedence is
+2,3,1  (inside spec, body config, spec config).
+
+Unfortunately, this means rethinking our implementation strategy ;-).
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 24, 2000 8:58 AM
+
+What would you prefer?
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Friday, March 24, 2000 11:23 AM
+
+The GNAT rule is OK.  However, at the moment we use the
+config pragma suppression state to initialize the declarative
+region suppression state when entering a package, and then save
+the suppression state for use when we get to the body.
+At that point we could put the body config either in front or
+in back of the spec info, but we couldn't put it in the "middle"
+between the spec config and the spec-internal pragma.
+
+Hence, we could relatively easily handle a precedence of:
+
+   body config, spec-internal, spec config
+ or
+   spec-internal, spec config, body config
+
+but not as easily handle:
+
+   spec-internal, body config, spec config
+
+since we have already "combined" spec-internal and spec-config in
+the information we saved when we reached the end of the package spec.
+
+For what it is worth, of the two we can more easily handle, I prefer
+giving precedence to the body config pragma, since that is the one
+that is sitting there visible in the source file containing the body.
+This would make a "config" pragma roughly equivalent to inserting
+the pragma immediately *within* each of the compilation units in the
+file, thereby overriding pragmas inherited from the spec/stub context.
+
+At this point, however, I am more interested in getting a definitive
+answer, and living with it, than debating all the pros and cons.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 24, 2000 3:07 PM
+
+Let's make absolutely sure we know what GNAT does, can you prepare a
+test program (just use a simple range check as the example perhaps).
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 24, 2000 2:52 PM
+
+> I hate to restart this firestorm, but I believe you still don't adequately
+> deal with configuration pragmas that apply to a particular source file.
+> Are their effects inherited by bodies that are in different source files,
+> if the spec is in a file that contains a config pragma?
+
+I do deal with them in the AI, but I really don't think that going further
+is appropriate in the pragma Unsuppress AI. But in any case, I don't expect
+a firestorm here, because I at least don't care much either way. (With one
+exception, noted below).
+
+> If so, and the body's file has one as well, does the body's config pragma
+> supersede the spec's config pragma, but *not* supersede a pragma declared
+> *inside* the package spec?  E.g., in this example, what is the order of
+> precedence for the following 3 pragmas:
+>
+>     file 1:
+>          pragma1;
+>
+>          package foo is
+>              pragma2;
+>              ...
+>          end foo;
+>
+>     file 2:
+>          pragma 3;
+>
+>          package body foo is
+>               --- what is precedence order of pragmas?
+>                    2 (highest), 1, 3
+>                    2, 3, 1
+>                    3,2,1
+>                    3,2 (1 is irrelevant here)
+>                    3 (1 and 2 are irrelevant here)
+>                    other combos?
+>
+>             ...
+
+Assuming the three pragmas are all checking pragmas (that is,
+Suppress/Unsuppress). Then my answer is as follows:
+
+The crucial question is "what declarative region does a configuration
+checking pragma apply to"?
+
+It is clear from 10.1.5(8) that pragma 1 does not (directly) apply to the
+package body. However, it might apply based on what declarative region it
+applies to.
+
+I see three possibilities here:
+
+1) The pragma applies only to the unit in the source file. This
+interpretation follows directly from 10.1.5(8), no fudge necessary.
+
+2) The pragma applies to all units compiled after it. This, I fear, is what
+the RM actually says. The pragma clearly applies to the environment
+declarative region, and that never ends for a particular program.
+
+3) The pragma somehow applies only inside of the units that it applies to.
+That would give the interpretation that Robert says GNAT is using. I don't
+see any justification in the standard for this interpretation, but it does
+have implementation advantages.
+
+I find the first possibility the most appealing. The second possibility is
+horrible, as setting such a pragma could only be turned off by compiling
+another pragma. I don't think anyone wants that.
+
+I view inheritance of Suppress pragmas as very dangerous, and would prefer
+to limit it as much as possible. In particular, the third possibility makes
+it impossible to use my standard approach to testing: compile the
+specifications with checking off and the bodies with checking on. (There is
+very little in the way of useful checks in specifications, but there is
+overhead, particularly for elaboration checks). We generally use pragmas in
+the source code, controlled by Janus/Ada's conditional compilation flags.
+
+All of that said, however, the most important thing is that compilers are
+consistent here, not which interpretation is taken. And it's important to
+note that this has nothing whatsoever to do with pragma Unsuppress, and
+should be handled in a separate, normal AI. (Robert has said what GNAT does;
+what do other compilers do?)
+
+---
+
+Now, to answer the other question (which I did cover in the AI).  If
+interpretation 1 above is taken, pragma 3 is clearly in a declarative region
+outside of the unit, while the inherited pragma 2 is clearly inside the
+unit. Thus 3 is applied first, then 2, and 1 is irrelevant.
+
+If interpretation 2 is taken, the answer is the same except that 1 applies
+first, then 3, then 2.
+
+If interpretation 3 is taken, pragmas 1, 2, and 3 clearly are inside of the
+unit, so they apply in the order that they are given in. That is probably 1,
+2, 3 or 1, 3, 2, depending on how the "magic" that pulls these pragmas
+inside is defined. However, the 1, 2, 3 order has significant usability
+problems for Unsuppress (discussed in the AI), so I hope that the "magic" is
+defined so that the 1, 3, 2 order that Robert says GNAT uses is what in fact
+applies.
+
+So, I think we need a two step process here: 1) decide on the real scope of
+a pragma Suppress given as a configuration pragma in a file with other
+units; then
+2) decide what should be said in Unsuppress to insure that the order is
+correct.
+
+(Note that the order that the pragmas are applied in only matters if we have
+a pragma Unsuppress; Suppress alone is essentially order-free).
+
+If we adopt GNAT's decision on the first question, then its implementation
+is by far the best interpretation for Unsuppress, and we need to contort the
+RM wording until we get that solution.
+
+If we adopt the non-inheritance wording, then the interpretation for
+Unsuppress works out properly for free.
+
+If we need it, I can write up a sample program to determine what compilers
+actually do.
+
+*************************************************************
+