digitalmars.D.bugs - [Issue 3170] New: Forward reference bugs
- d-bugmail puremagic.com Jul 13 2009
- d-bugmail puremagic.com Jul 13 2009
- d-bugmail puremagic.com Jul 13 2009
- d-bugmail puremagic.com Jul 13 2009
- d-bugmail puremagic.com Jul 14 2009
- d-bugmail puremagic.com Jul 14 2009
- d-bugmail puremagic.com Jul 15 2009
- d-bugmail puremagic.com Jul 15 2009
- d-bugmail puremagic.com Jul 15 2009
- d-bugmail puremagic.com Jul 15 2009
- d-bugmail puremagic.com Jul 15 2009
- d-bugmail puremagic.com Jul 16 2009
- d-bugmail puremagic.com Jul 16 2009
- d-bugmail puremagic.com Sep 03 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 Summary: Forward reference bugs Product: D Version: 2.031 Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: tim.matthews7 gmail.com Created an attachment (id=422) --> (http://d.puremagic.com/issues/attachment.cgi?id=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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 13 2009
d-bugmail puremagic.com http://d.puremagic.com/issues/show_bug.cgi?id=3170 --- Comment #1 from Tim M <tim.matthews7 gmail.com> 2009-07-13 03:08:33 PDT --- Created an attachment (id=423) --> (http://d.puremagic.com/issues/attachment.cgi?id=423) Reproducible B -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 13 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 Stewart Gordon <smjg iname.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rejects-valid CC| |smjg iname.com Version|2.031 |1.045 Blocks| |340 --- Comment #2 from Stewart Gordon <smjg iname.com> 2009-07-13 13:44:40 PDT --- 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) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 13 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 Stewart Gordon <smjg iname.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Forward reference bugs |Forward reference of nested | |class fails if outer class | |is abstract or derived --- Comment #3 from Stewart Gordon <smjg iname.com> 2009-07-13 13:53:11 PDT --- 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....) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 13 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com --- Comment #4 from Walter Bright <bugzilla digitalmars.com> 2009-07-14 22:40:35 PDT --- 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.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 14 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 Tim M <tim.matthews7 gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|1.045 |2.031 Summary|Forward reference of nested |Forward reference of nested |class fails if outer class |class fails if outer class |is abstract or derived |is not plain --- Comment #5 from Tim M <tim.matthews7 gmail.com> 2009-07-14 23:56:01 PDT --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 14 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 Stewart Gordon <smjg iname.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|2.031 |1.045 --- Comment #6 from Stewart Gordon <smjg iname.com> 2009-07-15 06:14:23 PDT --- (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.htmland 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 15 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.au --- Comment #7 from Don <clugdbug yahoo.com.au> 2009-07-15 06:46:27 PDT --- (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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 15 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 Cristi Vlasceanu <cristian zerobugs.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cristian zerobugs.org Version|1.045 |2.031 --- Comment #8 from Cristi Vlasceanu <cristian zerobugs.org> 2009-07-15 08:57:43 PDT --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 15 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 Stewart Gordon <smjg iname.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|2.031 |1.045 --- Comment #9 from Stewart Gordon <smjg iname.com> 2009-07-15 09:37:07 PDT --- (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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 15 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 --- Comment #10 from Walter Bright <bugzilla digitalmars.com> 2009-07-15 20:26:55 PDT --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 15 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 --- Comment #11 from Don <clugdbug yahoo.com.au> 2009-07-16 01:02:36 PDT ---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.
-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 16 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 Matti Niemenmaa <matti.niemenmaa+dbugzilla iki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matti.niemenmaa+dbugzilla i | |ki.fi --- Comment #12 from Matti Niemenmaa <matti.niemenmaa+dbugzilla iki.fi> 2009-07-16 07:03:35 PDT --- (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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 16 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3170 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #13 from Walter Bright <bugzilla digitalmars.com> 2009-09-03 13:26:07 PDT --- Fixed dmd 1.047 and 2.032 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 03 2009