* A compiler Bug? or a bug in the LRM??
@ 1988-05-05 16:16 Marc.Graham
0 siblings, 0 replies; 3+ messages in thread
From: Marc.Graham @ 1988-05-05 16:16 UTC (permalink / 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: A compiler Bug? or a bug in the LRM??
@ 1988-05-11 18:09 Keith Shillington @prodigal
0 siblings, 0 replies; 3+ messages in thread
From: Keith Shillington @prodigal @ 1988-05-11 18:09 UTC (permalink / raw)
The TeleSoft compiler on SUN compiles the program with no error.
I fully agree that 6.6:1 states that the program you have written is
indeed correct.
I have annotated your 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; -- B.T1
begin
P1(T1(x),y); -- B.P1( B.T1(x),y);
end C;
--------------------------------------------
This code does not violate 6.4.1:3.
Keith Shillington
TeleSoft, Education Group
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: A compiler Bug? or a bug in the LRM??
@ 1988-05-12 17:53 IVANOVIC%VAXR
0 siblings, 0 replies; 3+ messages in thread
From: IVANOVIC%VAXR @ 1988-05-12 17:53 UTC (permalink / raw)
telesoft!keith@ucsd.edu (Keith Shillington @prodigal) writes:
The TeleSoft compiler on SUN compiles the program with no error.
I fully agree that 6.6:1 states that the program you have written is
indeed correct.
[...]
This code does not violate 6.4.1:3.
Here is the output of DEC's Ada compiler:
1 package A is
2 type T1 is new Integer;
3 procedure P1 (Target : out T1; source : in T1);
4 end A;
5
6 with A;
7 Package B is
8 subtype T1 is A.T1;
9 procedure P1 (Target : out T1; source : in T1)
10 renames A.P1;
11 end B;
12
13 with B; use B;
14 procedure C is
15 type T2 is new T1;
16 x : T2;
17 y : T1; -- B.T1
18 begin
19 P1(T1(x),y); -- B.P1( B.T1(x),y);
...............1.2
%ADAC-E-CONFDENOT, (1) Subtype T1 in B at line 8 is not the same as type T1 in A
at line 2, which is denoted in B at line 9 (from A at line 3) [LRM 6.3.1]
%ADAC-I-CONFWITHTYPEMAR, (2) Error detected during conformance check with type
mark of subprogram 'out' formal Target in B at line 9
20 end C;
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1988-05-12 17:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1988-05-05 16:16 A compiler Bug? or a bug in the LRM?? Marc.Graham
-- strict thread matches above, loose matches on Subject: below --
1988-05-11 18:09 Keith Shillington @prodigal
1988-05-12 17:53 IVANOVIC%VAXR
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox