From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!pasteur!ucbvax!SEI.CMU.EDU!Marc.Graham From: Marc.Graham@SEI.CMU.EDU Newsgroups: comp.lang.ada Subject: A compiler Bug? or a bug in the LRM?? Message-ID: <8805051616.AA18489@bx.sei.cmu.edu> Date: 5 May 88 16:16:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: 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