!standard 8.3.1(3-4) 11-01-28 AC95-00214/01 !standard 9.4(11.10) !standard 9.4(11.11) !standard 9.5.2(5) !class confirmation 11-01-28 !status received no action 11-01-28 !status received 10-12-20 !subject Conflict between inherited subprogram and label !summary !appendix !topic Conflict between inherited subprogram and label !reference 5.1(12), 8.3(9-13) !from Adam Beneschan 10-12-20 !discussion This was reported as a problem with our compiler, which rejects this program while GNAT accepts it. After checking into the language rules, I believe that our compiler is correct, but the consequences of the rules are a bit surprising. package Pack1 is type Root is record F1 : Integer; end record; function Label1 (X : Root) return Integer; end Pack1; with Pack1; procedure Proc1 is begin declare type Child is new Pack1.Root; C : Child := (F1 => 0); begin Label1: for I in 1 .. 10 loop C.F1 := C.F1 + 1; end loop Label1; end; end Proc1; The issue is that the derived type declaration causes an implicit declaration Label1 to be declared; and the label Label1 also causes an implicit declaration to be declared in the same declarative_part (5.1(12)). These declarations are homographs since the label declaration is not overloadable. 8.3(9) says, "Two homographs are not generally allowed immediately within the same declarative region unless one overrides the other (see Legality Rules below)." This is followed by a definition of what constitues "overriding". But 8.3(10) doesn't apply; although the label Label1 appears explicitly on the loop, the declaration in the same declarative_part is implicit because 5.1(12) says so, and of course the inherited function Label1 is implicit. 8.3(11-13) are clearly not applicable (in particular, 8.3(12.1-12.3) only applies when all homographs are subprograms). So based on this, I'd conclude that the program is illegal because there are two homographs and neither one overrides the other. Is this analysis correct? Or am I applying the wrong rule because 8.3(9) is in a "Static Semantics" and not a "Legality Rules" section? If the latter is true, then I think the RM is confusing because the Static Semantics appears to say that something is illegal that isn't, and some clarification is needed. If my analysis is correct and the program really is illegal, it seems a bit surprising to me, since although there is an "implicit" declaration of Label1 according to 5.1(12), this declaration is derived (*) from an explicit declaration in the same scope, so it would seem that the explicit declaration ought to override the implicit one. Should a bullet point be added after 8.3(13) like this? . The implicit declaration corresponding to a statement_identifier (see 5.1(12)) overrides an implicit subprogram declaration. *************************************************************** From: Adam Beneschan Sent: Monday, December 20, 2010 11:20 AM I left something out of my last mail: > If my analysis is correct and the program really is illegal, it seems > a bit surprising to me, since although there is an "implicit" > declaration of Label1 according to 5.1(12), this declaration is > derived (*) from an explicit declaration in the same scope, so it > would seem that the explicit declaration ought to override the > implicit one. Should a bullet point be added after 8.3(13) like this? (*) I'm using "derived" in an English sense, not with any Ada meaning. *************************************************************** From: Randy Brukardt Sent: Friday, January 28, 2011 11:12 PM ... > So based on this, I'd conclude that the program is illegal because > there are two homographs and neither one overrides the other. Is this > analysis correct? Yes, I think it is correct. It must be because Janus/Ada agrees with your compiler! :-) In File D:\Testing\Win\console\adam.ada at line 15 -------------- 14: begin 15: Label1: --------------------^ *ERROR* Multiply defined identifier (6.4.3) Continue or Abort <^C>? The error message wouldn't help anybody figure out what went wrong, but clearly Janus/Ada decided that the two homographs conflicted. This is a case where I don't think it matters much what happens so long as it is well-defined. And we really don't want to start allowing homographs in the same scope (that would change an important invariant; I'm pretty sure our compiler depends on it in many places), so I think the language is fine. Just another reason to minimize derivations... ***************************************************************