Jump to page: 1 2
Thread overview
[Issue 3170] New: Forward reference bugs
Jul 13, 2009
Tim M
Jul 13, 2009
Stewart Gordon
[Issue 3170] Forward reference of nested class fails if outer class is abstract or derived
Jul 13, 2009
Stewart Gordon
Jul 15, 2009
Walter Bright
[Issue 3170] Forward reference of nested class fails if outer class is not plain
Jul 15, 2009
Tim M
Jul 15, 2009
Stewart Gordon
Jul 15, 2009
Don
Jul 15, 2009
Cristi Vlasceanu
Jul 15, 2009
Stewart Gordon
Jul 16, 2009
Walter Bright
Jul 16, 2009
Don
Jul 16, 2009
Matti Niemenmaa
Sep 03, 2009
Walter Bright
July 13, 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: -------
July 13, 2009
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: -------
July 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: -------
July 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: -------
July 15, 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: -------
July 15, 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: -------
July 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 #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.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: -------
July 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: -------
July 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: -------
July 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: -------
« First   ‹ Prev
1 2