[comp.lang.ada] A compiler Bug? or a bug in the LRM??

Marc.Graham@SEI.CMU.EDU (05/05/88)

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
                   

keith@telesoft.UUCP (Keith Shillington @prodigal) (05/12/88)

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

IVANOVIC%VAXR@CIRCUS.LLNL.GOV.UUCP (05/12/88)

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;