CVS difference for 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 @@
!wording
-TDB.
+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
+permissions.
+
+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.
+
!discussion
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
+Finalize.
+
+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