digitalmars.D.bugs - [Issue 3170] New: Forward reference bugs
- d-bugmail puremagic.com (27/27) Jul 13 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
- d-bugmail puremagic.com (8/8) Jul 13 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
- d-bugmail puremagic.com (33/33) Jul 13 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
- d-bugmail puremagic.com (30/30) Jul 13 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
- d-bugmail puremagic.com (21/21) Jul 14 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
- d-bugmail puremagic.com (20/20) Jul 14 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
- d-bugmail puremagic.com (17/21) Jul 15 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
- d-bugmail puremagic.com (22/29) Jul 15 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
- d-bugmail puremagic.com (19/19) Jul 15 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
- d-bugmail puremagic.com (27/48) Jul 15 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
- d-bugmail puremagic.com (8/8) Jul 15 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
- d-bugmail puremagic.com (15/29) Jul 16 2009 Because you can't do a search for "1.x bugs", you can only search for "1...
- d-bugmail puremagic.com (13/21) Jul 16 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
- d-bugmail puremagic.com (11/11) Sep 03 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3170
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
http://d.puremagic.com/issues/show_bug.cgi?id=3170 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
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
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
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
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
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.
--
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
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
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
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.
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 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=3170Because 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.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?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.Like what?- if a bug exists in both 1.x and 2.x, the 1.x version is setThat used to work well, when the compilers were almost identical. We're now getting a lot of bugs which are 1.x only.-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------Adding keywords is extremely helpful.Agreed.
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
2009-07-16 07:03:35 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.
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
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









d-bugmail puremagic.com 