CVS difference for ai05s/ai05-0019-1.txt

Differences between 1.5 and version 1.6
Log of other versions for file ai05s/ai05-0019-1.txt

--- ai05s/ai05-0019-1.txt	2007/01/19 04:00:06	1.5
+++ ai05s/ai05-0019-1.txt	2007/04/05 01:49:14	1.6
@@ -1,4 +1,4 @@
-!standard 13.14(15.1/2)                                  06-11-10    AI05-0019-1/01
+!standard 13.14(15.1/2)                                  07-04-04    AI05-0019-1/02
 !class binding interpretation 06-11-10
 !status work item 06-11-10
 !status received 06-11-09
@@ -46,8 +46,62 @@
+Add after 13.14(2):
+This clause also defines a place in the program text where the profile of each declared
+callable entity becomes "frozen". A use of a callable entity causes freezing of its
+profile in some contexts, as described below. At the place where the profile of a
+callable entity becomes frozen, the entity itself becomes frozen.
+Change 13.14(3/1) as follows:
+The end of a declarative_part, protected_body, or a declaration of a library package
+or generic library package, causes freezing of each entity {and profile} declared within
+it, except for incomplete types. A noninstance body other than a renames-as-body causes
+freezing of each entity {and profile} declared before it within the same declarative_part.
+[Author's note: Darn! The same paragraph is touched by another AI.]
+Change 13.14(8.1/1) as follows:
+An implicit call freezes the same entities {and profiles} that would be frozen by an
+explicit call. This is true even if the implicit call is removed via implementation
+Add after 13.14(10):
+o   At the place where a function call causes freezing, the profile of the function is
+    frozen.  Furthermore, if a parameter of the call is defaulted, the
+    default_expression for that parameter causes freezing.
+AARM Note: This is the important rule: a call freezes the profile. Note that we don't
+need to consider procedure or entry calls, because the end of a declarative_part freezes
+everything. We are moving here the part about defaulted parameters in function calls:
+it used to be in 13.14(14), but that paragraph is now only concerned with profiles, not calls.
+o   At the place where a generic_instantiation causes freezing of a callable entity, the
+    profile of that entity is frozen.
+AARM Note: The generic might call the actual for one of its formal subprograms, so we need
+to know the profile.
+Change 13.14(14) as follows:
+At the place where a [callable entity] {profile} is frozen, each subtype of [its] {the}
+profile is frozen. If the {corresponding} callable entity is a member of an entry family,
+the index subtype of the family is frozen. [At the place where a function call causes
+freezing, if a parameter of the call is defaulted, the default_expression for that
+parameter causes freezing.]
+Change 13.14(15.1/2) as follows:
+o  At the place where a specific tagged type is frozen, the primitive subprograms
+   of the type are frozen. {At the place where a type is frozen, any subprogram named
+   in an attribute_definition_clause for the type is frozen.}
+AARM Note: This is the rule that makes it possible to check 13.3(6) without going
+through hoops.
 Here's another example of the problem with the original rule:
@@ -88,6 +142,51 @@
 This rule change will not eliminate all incompatibilities with this rule, just the
 worst cases. Non-tagged parameters and all function return types will continue
 to be frozen, possibly requiring some reorganization of the code.
+Another problem that came up in the discussion is this: 13.3(6) says that a subprogram
+used in an attribute_definition_clause must have convention Ada. This is nasty 
+because the subprogram may only be frozen *after* the type to which the
+attribute_definition_clause is applied:
+    type My_Int is range 0 .. 100;
+    procedure Bad_Output
+		 (Stream : not null access Ada.Streams.Root_Stream_Type'Class;
+		  A : in My_Int'Base);
+    for My_Int'Output use Bad_Output;
+    X : My_Int;
+    pragma Convention (C, Bad_Output); -- Wrong convention, but too late...
+It seems that this example is somewhat related to the one in AI95-00341: a type
+gets frozen before everything is known about its "important" subprograms.
+The solution is to separate the freezing of a callable entity from that of its profile.
+When a subprogram is frozen, it is not possible to give representation items for it.
+Therefore, the pragma Convention in the example above is illegal, because the declaration
+of X freezes My_Int which freezes Bad_Output. Similarly, in the example of AI95-00341,
+the address clause is illegal because the declaration of X freezes Ctrl which freezes
+Thus, the freezing rules ensure that at the (first) freezing point for a type the
+compiler knows enough about the "important" subprograms to be able to generate the
+dispatch table and other type-specific data structures. It can also perform all the
+necessary legality checks regarding these subprograms.
+Still, freezing a subprogram does not (necessarily) freezes its *profile*. The reason
+is that the profile needs only be frozen when the compiler needs to generate code for
+a call (at which point it must know the sizes, passing conventions, etc. for the parameters).
+So the only constructs that need to freeze a profile are those that can call the
+subprogram: this includes (function) calls, generic instantiations, bodies, the end
+of declarative parts, and the end of compilation units.
+If we look at the example in the !question, we see that the declaration of Object
+freezes T2, which freezes the *subprogram* Primitive, but not its *profile*. Therefore,
+T1 is *not* frozen (yet), and the source code is legal. T1 (and the profile of
+Primitive) will only be frozen at the end of the compilation unit.
 !ACATS test

Questions? Ask the ACAA Technical Agent