Bug 3170 – Forward reference of nested class fails if outer class is not plain

Created attachment 422 Reproducible A In order for the dnet (D dot net compiler based on dmd front end) to work, import files for the dot net declarations must be generated. Currently the import files cannot be parsed and the error thrown is: Error: class System.Windows.Forms.ToolStripItem is forward referenced when looking for 'ToolStripItemAccessibleObject' I have reduced this down to 2 separate reproducible cases (see attached). Having both of these fixed will make .net interoperability via dnet compiler more achievable and help D generally drop forward reference issues that C++ is prone too.

Created attachment 423 Reproducible B

Please remember to assign keywords to bug reports. To everybody reading this: Please look through issues you've reported and check for missing keywords. And please report the full compiler output from the testcases you post. It makes it far easier for all of us to see what's going on. C:\Users\Stewart\Documents\Programming\D\Tests\bugs>dmd bz3170a.d bz3170a.d(8): Error: class reproA.C is forward referenced when looking for 'D' bz3170a.d(8): Error: class reproA.C is forward referenced when looking for 'D' bz3170a.d(8): Error: class reproA.C is forward referenced when looking for 'D' bz3170a.d(5): Error: no property 'D' for type 'reproA.C' bz3170a.d(5): Error: C.D is used as a type bz3170a.d(5): Error: class reproA.A.B base type must be class or interface, not void C:\Users\Stewart\Documents\Programming\D\Tests\bugs>dmd bz3170b.d bz3170b.d(9): Error: class reproB.C is forward referenced when looking for 'D' bz3170b.d(9): Error: class reproB.C is forward referenced when looking for 'D' bz3170b.d(9): Error: class reproB.C is forward referenced when looking for 'D' bz3170b.d(5): Error: no property 'D' for type 'reproB.C' bz3170b.d(5): Error: C.D is used as a type bz3170b.d(5): Error: class reproB.A.B base type must be class or interface, not void (DMD 1.045 Win)

Another case that fails: ---------- class A { class B : C.D { } } class C : E { class D { } } class E { } ---------- bz3170c.d(5): Error: class bz3170c.C is forward referenced when looking for 'D' bz3170c.d(5): Error: class bz3170c.C is forward referenced when looking for 'D' bz3170c.d(5): Error: class bz3170c.C is forward referenced when looking for 'D' bz3170c.d(2): Error: no property 'D' for type 'bz3170c.C' bz3170c.d(2): Error: C.D is used as a type bz3170c.d(2): Error: class bz3170c.A.B base type must be class or interface, not void ---------- (Seems that the presence or absence of static doesn't affect the bug....)

This case: ---------- class A { class B : C.D { } } class C : E { class D { } } class E { } ---------- is wrong anyway because C.D is nested inside C, and cannot be instantiated inside of A. (Because of the lack of an appropriate 'this' reference to use.)

Stewart Gordon if you want to be a bugzilla cop can you please take care. You changed the subject name but is not quite correct. The abstract keyword can be replaced with many other keywords like public, protected, private etc. The problem is that you can only forward reference to a nested class within a plain outer class. I will update the summary. You also changed the version to 1.045. I am reverting it back to 2.031 as this has the most up to date forward reference implementation and is also the version dnet(the software that this issue is for) is currently based on.

(In reply to comment #5) > You also changed the version to 1.045. I am reverting it back to 2.031 as this > has the most up to date forward reference implementation No, the policy here is that - we set the _oldest_ version in which the bug has been witnessed - if a bug exists in both 1.x and 2.x, the 1.x version is set Just one post along these lines (there are others): http://www.digitalmars.com/d/archives/digitalmars/D/bugs/bugzilla_usage_tips_10071.html > and is also the version dnet(the software that this issue is for) > is currently based on. This bug is rooted in DMD, not in dnet. What third-party compilers inherit a bug is irrelevant to the filing of it here.

(In reply to comment #6) > (In reply to comment #5) > > You also changed the version to 1.045. I am reverting it back to 2.031 as this > > has the most up to date forward reference implementation > > No, the policy here is that > - we set the _oldest_ version in which the bug has been witnessed That turns out to be completely useless, actually. It'd be _so_ much better if there were only 3 versions: 1.x, 2.x, both. For one thing, it means that any search for "1.x bugs" becomes invalid every time there's a new compiler version! And the exact version number is relevant only when there's a regression. And that's handled better by a comment, anyway. > - if a bug exists in both 1.x and 2.x, the 1.x version is set That used to work well, when the compilers were almost identical. We're now getting a lot of bugs which are 1.x only. You're right about it being the policy, but it's actually not a helpful policy at all. (OTOH, updating the version number to the most recent DMD is *really* bad). Adding keywords is extremely helpful.

Tim is right and I second the opinion that people that are just playing bugzilla cops for the sake of it should not, if they do not understand the bigger picture. Walter made some changes to how forward references are handled in the 2.031 source. The intent of the bug report is to say that _after_ those changes, there are still issues. Also, because according to Walter, forward ref bugs are tricky, we probably _do not_ want the 1.x code base fixed, since the "fixes" could have bad side effects.

(In reply to comment #7) >> No, the policy here is that >> - we set the _oldest_ version in which the bug has been witnessed > > That turns out to be completely useless, actually. It'd be _so_ > much better if there were only 3 versions: 1.x, 2.x, both. Maybe. But until and unless this change happens, setting a bug that's present in both lines to a 2.x version is misleading, since by current policy it gives the impression that it's a (DM)D2-specific bug. > For one thing, it means that any search for "1.x bugs" becomes invalid every > time there's a new compiler version! How do you work that out? >> - if a bug exists in both 1.x and 2.x, the 1.x version is set > > That used to work well, when the compilers were almost identical. We're now > getting a lot of bugs which are 1.x only. Like what? > Adding keywords is extremely helpful. Agreed. (In reply to comment #8) > Tim is right and I second the opinion that people that are just playing > bugzilla cops for the sake of it should not, if they do not understand the > bigger picture. Well, nobody here is playing a bugzilla cop for the sake of it. I for one hold that it's practically better if the information is accurate and not misleading (see my response to Don above). > Walter made some changes to how forward references are handled in the 2.031 > source. The intent of the bug report is to say that _after_ those changes, > there are still issues. The fact is that the bug exists in the D1 line, and as such the version field should reflect this fact. Maybe Walter'll tell us (or someone'll study the code and find out) that, because of these changes, the underlying cause is different and thus the fix is different. But then it's a matter of writing the fix for each (and considering whether this should be two separate bug reports), not of pretending it doesn't exist in 1.x. > Also, because according to Walter, forward ref bugs are tricky, we > probably _do not_ want the 1.x code base fixed, since the "fixes" > could have bad side effects. Possibly, but it's not up to you to decide for him.

I've emailed the fix to Cristi. For what it's worth, the problem and fix is identical for D 1 and 2. It should not break any existing working code. I won't mark this as fixed, however, until the release happens.

> > For one thing, it means that any search for "1.x bugs" becomes invalid every > > time there's a new compiler version! > > How do you work that out? Because you can't do a search for "1.x bugs", you can only search for "1.0 + 1.01+ 1.02+... + 1.045". Then 1.046 gets added, and it's not in your search. I'm getting really sick of it. > >> - if a bug exists in both 1.x and 2.x, the 1.x version is set > > > > That used to work well, when the compilers were almost identical. We're now > > getting a lot of bugs which are 1.x only. > > Like what? From my list of unpatched ICE bugs, there are 9 which are D1-specific: 1144, 1934, 2229, 2687, 1897, 3160, 1787, 2080, 2851. There are 9 which are D2-specific. There are another 7 which are common to both (this number is artificially low, since there are the ones I put most effort into). The difference in the compiler internals is increasing, so some patches which work for D2 don't work for D1, and vice versa. > > > Adding keywords is extremely helpful. > > Agreed.

(In reply to comment #11) > > > For one thing, it means that any search for "1.x bugs" becomes invalid every > > > time there's a new compiler version! > > > > How do you work that out? > > Because you can't do a search for "1.x bugs", you can only search for "1.0 + > 1.01+ 1.02+... + 1.045". Then 1.046 gets added, and it's not in your search. > I'm getting really sick of it. See the bottom of http://d.puremagic.com/issues/query.cgi - "Advanced searching using boolean charts". Version - is less than - 2 seems to work just fine.

Fixed dmd 1.047 and 2.032