6.3.1 Conformance Rules
{conformance}
[When
subprogram profiles are given in more than one place, they are required
to conform in one of four ways: type conformance, mode conformance, subtype
conformance, or full conformance.]
Static Semantics
{
8652/0011}
{
AI95-00117-01}
{convention} {calling
convention} [As explained in
B.1,
“
Interfacing Pragmas”, a
convention
can be specified for an entity.] Unless this International Standard states
otherwise, the default convention of an entity is Ada. [For a callable
entity or access-to-subprogram type, the convention is called the
calling
convention.] The following conventions are defined by the language:
{Ada calling convention}
{calling convention
(Ada)} The default calling convention
for any subprogram not listed below is
Ada. [A
pragma
Convention, Import, or Export may be used to override the default calling
convention (see
B.1)].
Ramification: See also the rule about
renamings-as-body in
8.5.4.
{Intrinsic
calling convention} {calling
convention (Intrinsic)} The
Intrinsic
calling convention represents subprograms that are “built in”
to the compiler. The default calling convention is Intrinsic for the
following:
an enumeration literal;
a "/=" operator declared
implicitly due to the declaration of "=" (see
6.6);
any other implicitly declared subprogram
unless it is a dispatching operation of a tagged type;
an inherited subprogram of a generic
formal tagged type with unknown discriminants;
Reason: Consider:
package P is
type Root is tagged null record;
procedure Proc(X: Root);
end P;
generic
type Formal(<>) is new Root with private;
package G is
...
end G;
package body G is
...
X: Formal := ...;
...
Proc(X); -- This is a dispatching call in Instance, because
-- the actual type for Formal is class-wide.
...
-- Proc'Access would be illegal here, because it is of
-- convention Intrinsic, by the above rule.
end G;
type Actual is new Root with ...;
procedure Proc(X: Actual);
package Instance is new G(Formal => Actual'Class);
-- It is legal to pass in a class-wide actual, because Formal
-- has unknown discriminants.
Within Instance, all calls to Proc will be dispatching
calls, so Proc doesn't really exist in machine code, so we wish to avoid
taking 'Access of it. This rule applies to those cases where the actual
type might be class-wide, and makes these Intrinsic, thus forbidding
'Access.
an attribute that is a subprogram;
Reason: The profile of a prefixed view
is different than the “real” profile of the subprogram (it
doesn't have the first parameter), so we don't want to be able to take
'Access of it, as that would require generating a wrapper of some sort.
[The Access attribute is not allowed for
Intrinsic subprograms.]
Ramification: The Intrinsic calling convention
really represents any number of calling conventions at the machine code
level; the compiler might have a different instruction sequence for each
intrinsic. That's why the Access attribute is disallowed. We do not wish
to require the implementation to generate an out of line body for an
intrinsic.
Whenever we wish to disallow the Access attribute
in order to ease implementation, we make the subprogram Intrinsic. Several
language-defined subprograms have “pragma Convention(Intrinsic,
...);”. An implementation might actually implement this as “pragma
Import(Intrinsic, ...);”, if there is really no body, and the implementation
of the subprogram is built into the code generator.
Subprograms declared in protected_bodies
will generally have a special calling convention so as to pass along
the identification of the current instance of the protected type. The
convention is not protected since such local subprograms need
not contain any “locking” logic since they are not callable
via “external” calls; this rule prevents an access value
designating such a subprogram from being passed outside the protected
unit.
The “implicitly declared subprogram”
above refers to predefined operators (other than the "=" of
a tagged type) and the inherited subprograms of untagged types.
{protected calling
convention} {calling
convention (protected)} The default calling
convention is
protected for a protected subprogram, and for an
access-to-subprogram type with the reserved word
protected in
its definition.
{entry calling
convention} {calling
convention (entry)} The default calling
convention is
entry for an entry.
{
AI95-00254-01}
{
AI95-00409-01}
The calling convention for an anonymous access-to-subprogram parameter
or anonymous access-to-subprogram result is
protected if the reserved
word
protected appears in its definition and otherwise is the
convention of the subprogram that contains the parameter.
Ramification: The calling convention
for other anonymous access-to-subprogram types is Ada.
{
8652/0011}
{
AI95-00117-01}
[If not specified above as Intrinsic, the calling convention for any
inherited or overriding dispatching operation of a tagged type is that
of the corresponding subprogram of the parent type.] The default calling
convention for a new dispatching operation of a tagged type is the convention
of the type.
Reason: The first rule is officially
stated in
3.9.2. The second is intended to
make interfacing to foreign OOP languages easier, by making the default
be that the type and operations all have the same convention.
Of these four conventions, only Ada and Intrinsic
are allowed as a
convention_identifier
in a
pragma
Convention, Import, or Export.
Discussion: The names of the protected
and entry calling conventions cannot be used in the interfacing
pragmas. Note that protected and entry are reserved words.
{
AI95-00409-01}
{type conformance} {profile
(type conformant)} Two profiles are
type
conformant if they have the same number of parameters, and both have
a result if either does, and corresponding parameter and result types
are the same, or, for access parameters or access results, corresponding
designated types are the same, or corresponding designated profiles are
type conformant.
{type profile: See profile,
type conformant} Discussion: {
AI95-00409-01}
For anonymous access-to-object parameters, the designated types have
to be the same for type conformance, not the access types, since in general
each access parameter has its own anonymous access type, created when
the subprogram is called. Of course, corresponding parameters have to
be either both access parameters or both not access parameters.
{
AI95-00409-01}
Similarly, for anonymous access-to-subprogram parameters, the designated
profiles of the types, not the types themselves, have to be conformant.
{
AI95-00318-02}
{
AI95-00409-01}
{mode conformance} {profile
(mode conformant)} Two profiles are
mode
conformant if they are type-conformant, and corresponding parameters
have identical modes, and, for access parameters or access result types,
the designated subtypes statically match, or the designated profiles
are subtype conformant.
{statically matching
(required) [partial]} {subtype conformance}
{profile (subtype
conformant)} Two profiles are
subtype
conformant if they are mode-conformant, corresponding subtypes of
the profile statically match, and the associated calling conventions
are the same. The profile of a generic formal subprogram is not subtype-conformant
with any other profile.
{statically matching
(required) [partial]}
Ramification: {
generic contract issue
[partial]}
{full conformance
(for profiles)} {profile
(fully conformant)} Two profiles are
fully
conformant if they are subtype-conformant, and corresponding parameters
have the same names and have
default_expressions
that are fully conformant with one another.
Ramification: Full conformance requires
subtype conformance, which requires the same calling conventions. However,
the calling convention of the declaration and body of a subprogram or
entry are always the same by definition.
{full
conformance (for expressions)} Two expressions
are
fully conformant if, [after replacing each use of an operator
with the equivalent
function_call:]
each constituent construct of one corresponds to
an instance of the same syntactic category in the other, except that
an expanded name may correspond to a
direct_name
(or
character_literal)
or to a different expanded name in the other; and
Ramification: Note that it doesn't say
“respectively” because a
direct_name
can correspond to a
selector_name,
and vice-versa, by the previous bullet. This rule allows the
prefix
of an expanded name to be removed, or replaced with a different
prefix
that denotes a renaming of the same entity. However, it does not allow
a
direct_name
or
selector_name
to be replaced with one denoting a distinct renaming (except for
direct_names
and
selector_names
in
prefixes
of expanded names). Note that calls using operator notation are equivalent
to calls using prefix notation.
Given the following
declarations:
package A is
function F(X : Integer := 1) return Boolean;
end A;
with A;
package B is
package A_View renames A;
function F_View(X : Integer := 9999) return Boolean renames F;
end B;
with A, B; use A, B;
procedure Main is ...
Within Main, the expressions “F”,
“A.F”, “B.A_View.F”, and “A_View.F”
are all fully conformant with one another. However, “F” and
“F_View” are not fully conformant. If they were, it would
be bad news, since the two denoted views have different
default_expressions.
each
primary
that is a literal in one has the same value as the corresponding literal
in the other.
Ramification: The literals may be written
differently.
Ramification: Note that the above definition
makes full conformance a transitive relation.
{full conformance
(for known_discriminant_parts)} Two
known_discriminant_parts
are
fully conformant if they have the same number of discriminants,
and discriminants in the same positions have the same names, statically
matching subtypes, and
default_expressions
that are fully conformant with one another.
{statically
matching (required) [partial]}
{
AI95-00345-01}
{
AI95-00397-01}
{prefixed view profile} The
prefixed view profile of a subprogram is the profile obtained
by omitting the first parameter of that subprogram. There is no prefixed
view profile for a parameterless subprogram. For the purposes of defining
subtype and mode conformance, the convention of a prefixed view profile
is considered to match that of either an entry or a protected operation.
Discussion: This definition is used to
define how primitive subprograms of interfaces match operations in task
and protected type definitions (see
9.1 and
9.4).
Reason: The weird rule about conventions
is pretty much required for synchronized interfaces to make any sense.
There will be wrappers all over the place for interfaces anyway. Of course,
this doesn't imply that entries have the same convention as protected
operations.
Implementation Permissions
An implementation may declare an operator declared
in a language-defined library unit to be intrinsic.
Extensions to Ada 83
{
extensions to Ada 83}
The
rules for full conformance are relaxed — they are now based on
the structure of constructs, rather than the sequence of lexical elements.
This implies, for example, that "(X, Y: T)" conforms fully
with "(X: T; Y: T)", and "(X: T)" conforms fully
with "(X:
in T)".
Wording Changes from Ada 95
{
8652/0011}
{
AI95-00117-01}
Corrigendum: Clarified that the default convention is Ada. Also
clarified that the convention of a primitive operation of a tagged type
is the same as that of the type.
{
AI95-00409-01}
Defined the conformance of anonymous access-to-subprogram parameters.
Sponsored by Ada-Europe