From: Marc.Graham@SEI.CMU.EDU
Subject: A compiler Bug? or a bug in the LRM??
Date: 5 May 88 16:16:37 GMT [thread overview]
Message-ID: <8805051616.AA18489@bx.sei.cmu.edu> (raw)
Please examine the following pieces of Ada code:
----------------------------------------------
package A is
type T1 is new Integer;
procedure P1 (Target : out T1; source : in T1);
end A;
with A;
Package B is
subtype T1 is A.T1;
procedure P1 (Target : out T1; source : in T1)
renames A.P1;
end B;
with B; use B;
procedure C is
type T2 is new T1;
x : T2;
y : T1;
begin
P1(T1(x),y);
end C;
--------------------------------------------
The Alsys compiler on my Sun produces the error message:
------------------
28 P1(T1(x),y);
^__^
1 1
1 : **SEM The type mark of the conversion to T1 must conform with the type
mark of the formal in_out or out parameter T1 - RM 6.4.1 (3).
-------------
On the other hand, if procedure C is changed to
---------------------------------------------
with B; with A;
procedure C is
type T2 is new B.T1;
x : T2;
y : B.T1;
begin
B.P1(A.T1(x),y);
end C;
----------------------------------------------
it compiles fine. Now 6.4.1(3) is about actual/formal parameter
correspondance. In particular, it reads
An actual ... associated with a formal ... of mode ... out must be
either ... or of the form of a type conversion whose argument is
the name of a variable. ... For an actual ... type conversion, the
type mark must conform (see 6.3.1) to the type mark of the formal ...
Now 6.3.1 is about conformance of subprogram specifications, i. e.,
formals, for different declarations of the same subprogram. The rule
there is pretty much `bitwise identity' with trivial departures, none
of which apply here. The applicable paragraph may well be (5) which
reads
Two subprogram specifications are said to conform if, ... ,both
specifications are formed by the same sequence of lexical elements,
and corresponding lexical elements are given the same meaning by the
visibility and overloading rules.
Now, clearly the compiler thinks the types of the parameters of B.P1
are A.T1, and it is correct to do so, according to 8.5 (8). So we come
to the interpretation of `lexical elements having the same meaning.' I
find it hard to argue that the Alsys interpretation (that T1 in B.P1
has the meaning A.T1; and that T1 in the original version of C has the
meaning B.T1; and that A.T1 and B.T1 are not the same, as `meanings')
is wrong.
So. is this a bug in the LRM? Should 6.4.1(3) reference 6.6 (Paramater
Type Profiles) instead of 6.3.1 (Conformance Rules)? The first
sentence of 6.6 reads
Two formal parts are said to have the same parameter type profile if
and only if they have the same number of parameters, and at each
parameter position corresponding parameters have the same base type.
(The possibility that the bug is in my code is rejected a priori.)
I certainly thought that the rules of 6.6 would have applied. What did
you think?
Marc H. Graham Software Engineering Institute
marc@sei.cmu.edu Carnegie Mellon University
(412) 268 7784 Pittsburgh, PA 15213
next reply other threads:[~1988-05-05 16:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1988-05-05 16:16 Marc.Graham [this message]
-- strict thread matches above, loose matches on Subject: below --
1988-05-11 18:09 A compiler Bug? or a bug in the LRM?? Keith Shillington @prodigal
1988-05-12 17:53 IVANOVIC%VAXR
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox