6.3.1 Conformance Rules
1
[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
2/1
{
8652/0011}
{
AI95-00117-01}
[As explained in
B.1,
“
Interfacing Aspects”, 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:
3/3
{
AI05-0229-1}
The default calling convention
for any subprogram not listed below is
Ada. [
The A
pragma
Convention
aspect,
Import, or Export may be
specified used
to override the default calling convention (see
B.1)].
3.a
Ramification: See also the rule about
renamings-as-body in
8.5.4.
4
The
Intrinsic calling convention represents subprograms that are “built
in” to the compiler. The default calling convention is Intrinsic
for the following:
5
an enumeration literal;
6
a "/=" operator declared
implicitly due to the declaration of "=" (see
6.6);
7
any other implicitly declared subprogram
unless it is a dispatching operation of a tagged type;
8
an inherited subprogram of a generic
formal tagged type with unknown discriminants;
8.a.1/1
Reason: Consider:
8.a.2/1
package P is
type Root is tagged null record;
procedure Proc(X: Root);
end P;
8.a.3/1
generic
type Formal(<>) is new Root with private;
package G is
...
end G;
8.a.4/1
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;
8.a.5/1
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.
8.a.6/1
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.
9
an attribute that is a subprogram;
10/2
10.1/2
10.a/2
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.
11
[The Access attribute is not allowed for
Intrinsic subprograms.]
11.a
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.
11.b/3
{
AI05-0229-1}
Whenever we wish to disallow the Access attribute in order to ease implementation,
we make the subprogram Intrinsic. Several language-defined subprograms
have “
with pragma
Convention
=> (Intrinsic
,
...);”. An implementation might actually implement this
as “
with pragma
Import
=> True, Convention => (Intrinsic
,
...);”, if there is really no body, and the implementation
of the subprogram is built into the code generator.
11.c
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.
11.d
The “implicitly declared subprogram”
above refers to predefined operators (other than the "=" of
a tagged type) and the inherited subprograms of untagged types.
12
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.
13
The default
calling convention is
entry for an entry.
13.1/3
{
AI95-00254-01}
{
AI95-00409-01}
{
AI05-0264-1}
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,
it is the convention of the subprogram that
contains the parameter. 13.a/2
Ramification: The
calling convention for other anonymous access-to-subprogram types is
Ada.
13.2/1
{
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. 13.a.1/1
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.
14/3
{
AI05-0229-1}
Of these four conventions, only Ada and Intrinsic are allowed as a
convention_identifier
in
the specification of a a
pragma
Convention
aspect,
Import, or Export.
14.a/3
Discussion: {
AI05-0229-1}
The names of the
protected and
entry calling conventions
cannot be used in the
specification of Convention interfacing
pragmas. Note that
protected and
entry are reserved
words.
15/2
{
AI95-00409-01}
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.
15.a/2
Discussion: {
AI95-00409-01}
For
anonymous access-to-object access
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.
15.b/2
{
AI95-00409-01}
Similarly, for anonymous access-to-subprogram parameters,
the designated profiles of the types, not the types themselves, have
to be conformant. 16/3
{
AI95-00318-02}
{
AI95-00409-01}
{
AI05-0142-4}
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. 16.1/3
16.2/3
{
AI05-0142-4}
corresponding parameters have identical modes and
both or neither are explicitly aliased parameters; and16.3/3
{
AI05-0207-1}
for corresponding access parameters and any access
result type, the designated subtypes statically match and either both
or neither are access-to-constant, or the designated profiles are subtype
conformant. 17/3
{
AI05-0239-1}
Two profiles are
subtype conformant
if they are
mode conformant 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 subtype-conformant
with any other profile.
17.a
18/3
{
AI05-0134-1}
{
AI05-0262-1}
Two
profiles are
fully conformant if they are
subtype
conformant subtype-conformant,
if
they have access-to-subprogram results whose designated profiles are
fully conformant, and
for corresponding
parameters
: have the
same names and have default_expressions
that are fully conformant with one another. 18.1/3
18.2/3
18.3/3
18.4/3
{
AI05-0134-1}
for access-to-subprogram parameters, the designated
profiles are fully conformant. 18.a
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.
18.b/3
Reason: {
AI05-0046-1}
The part about null_exclusions
is necessary to prevent controlling parameters from having different
exclusions, as such a parameter is defined to exclude null whether or
not an exclusion is given.
18.c/3
{
AI05-0134-1}
The parts about access-to-subprogram parameters
and results is necessary to prevent such types from having different
default_expressions
in the specification and body of a subprogram. If that was allowed, it
would be undefined which default_expression
was used in a call of an access-to-subprogram parameter. 19
Two
expressions are
fully conformant if, [after replacing each use
of an operator with the equivalent
function_call:]
20
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
21
21.a
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.
21.b
Given the following
declarations:
21.c
package A is
function F(X : Integer := 1) return Boolean;
end A;
21.c.1/3
{
AI05-0005-1}
with A;
package B
is
package A_View
renames A;
function F_View(X : Integer := 9999)
return Boolean
renames A. F;
end B;
21.d
with A, B; use A, B;
procedure Main is ...
21.e
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.
21.1/3
22
each
primary
that is a literal in one has the same value as the corresponding literal
in the other.
22.a
Ramification: The literals may be written
differently.
22.b
Ramification: Note that the above definition
makes full conformance a transitive relation.
23
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.
24
24.a
24.b
24.1/2
{
AI95-00345-01}
{
AI95-00397-01}
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.24.c/2
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).
24.d/2
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
25
An implementation may declare an operator declared
in a language-defined library unit to be intrinsic.
Extensions to Ada 83
25.a
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
25.b/2
{
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.25.c/2
25.d/2
25.e/2
25.f/2
25.g/2
{
AI95-00409-01}
Defined the conformance of anonymous access-to-subprogram
parameters. Incompatibilities With Ada 2005
25.h/3
{
AI05-0046-1}
Correction: Now require
null_exclusions
to match for full conformance. While this is technically incompatible
with Ada 2005 as defined by Amendment 1, it is a new Ada 2005 feature
and it is unlikely that users have been intentionally taking advantage
of the ability to write mismatching exclusions. In any case, it is easy
to fix: add a null_exclusion
where needed for conformance.25.i/3
{
AI05-0134-1}
Correction: Now require full conformance
of anonymous access-to-subprogram parameters and results for full conformance.
This is necessary so that there is no confusion about the default expression
that is used for a call. While this is technically incompatible with
Ada 2005 as defined by Amendment 1, it is a new Ada 2005 feature and
it is unlikely that users have been intentionally taking advantage and
writing different default expressions. In any case, it is easy to fix:
change any default expressions that don't conform so that they do conform.25.j/3
{
AI05-0207-1}
Correction: Now include the presence or
absence of constant in access parameters to be considered when
checking mode conformance. This is necessary to prevent modification
of constants. While this is technically incompatible with Ada 2005 as
defined by Amendment 1, it is a new Ada 2005 feature and it is unlikely
that users have been intentionally taking advantage and writing mismatching
access types. Wording Changes from Ada 2005
25.k/3
{
AI05-0142-4}
Explicitly aliased parameters are included as part
of mode conformance (since it affects the parameter passing mechanism).
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
