http://d.puremagic.com/issues/show_bug.cgi?id=102


dawid.ciezarkiewicz@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawid.ciezarkiewicz@gmail.co
                   |                            |m




------- Comment #1 from dawid.ciezarkiewicz@gmail.com  2006-07-31 02:35 -------
$ cat test1.d
import test2;

class X {
        Y.NY t;
        enum NX {
                BLA,
                BLA1
        }
}

$ cat test2.d
import test1;

class Y {
        X.NX nx;
        enum NY {
                FOO,
                BAR
        }
}

Is impossible to compile just like bug #102.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=102


davidl@126.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|0.153                       |1.00




------- Comment #2 from davidl@126.com  2007-01-23 05:15 -------
umm, let the compiler solve this kind of forward reference is painful i guess. d 1.0 doesn't let it through


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=102


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iceelyne@gmail.com




------- Comment #3 from smjg@iname.com  2007-02-11 20:21 -------
*** Bug 912 has been marked as a duplicate of this bug. ***


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=102


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au




--- Comment #4 from Don <clugdbug@yahoo.com.au>  2009-09-03 00:53:52 PDT ---
The original bug, and also the test case in bug 912, were fixed after 1.041 and before 1.047. They work in D2 as well. Only the 'enum' case in comment 2 remains unfixed!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=102





--- Comment #5 from Don <clugdbug@yahoo.com.au>  2009-09-03 06:49:57 PDT ---
This is the slightly reduced test case that still fails. It only needs one file.

class X {
  Y.NY t;
  enum NX { BLA, BLA1 }
}

class Y {
  enum NY { FOO, BAR }
  X.NX nx;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=102



--- Comment #6 from Rainer Schuetze <r.sagitario@gmx.de> 2009-09-18 01:33:06 PDT ---
Created an attachment (id=457)
more aggressive deferral of (possible) forward declarations

DMD has a mechanism to defer semantic analysis of declarations, but
uses it only sometimes when it detects a forward reference. Often you cannot
tell if it is a forward reference or a typo, so I have made this work more
aggressively.

Details:
A new state variable (tryfwd - better name suggestion welcome) is added to the
global struct, that switches the behaviour for VarDeclaration::semantic: if
analysis of the type produces an error, further analysis is deferred. Error
messages are suppressed by the gag-mechanism.

The same state variable is used to defer struct size analysis.

After the first semantic analysis step on all files on the command line, tryfwd is cleared, and semantic analysis is run again on all deferred symbols, producing appropriate error messages.

The downside of this patch is that it might have a negative impact
on compilation speed and memory consumption:
- depending on the modules layout semantic analysis on deferred symbols is run
very often or maybe not often enough.
- To avoid overwriting type information with erronuous info, a syntaxCopy is
run before the type analysis. This might need a lot of memory, but most types
are small or even do not create any copy at all (as the basic types).
- error messages are less sequential with respect to lexical order.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=102


Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                 CC|                            |r.sagitario@gmx.de


--- Comment #7 from Rainer Schuetze <r.sagitario@gmx.de> 2009-09-18 01:36:02 PDT ---
This patch also fixes issues 282, 400, 461, 1564, 2386, 2654 and 2666.

But before adding this info to these bugs, I'd like some feedback on the patch.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=102



--- Comment #8 from Don <clugdbug@yahoo.com.au> 2009-09-18 13:39:03 PDT ---
IMHO this is a VERY promising patch since it potentially fixes many difficult
issues. It's not quite complete though.
I've run it though Walter's test suite, and one test fails (all others pass).
The code below should fail to compile, but instead the compiler gets into an
infinite loop --- it's an ice-on-invalid-code regression.

----
struct A (T) {
       mixin B! (T, A! (T));
}

A!(int) x;
----

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=102


Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #457 is|0                           |1
           obsolete|                            |


--- Comment #9 from Rainer Schuetze <r.sagitario@gmx.de> 2009-09-19 05:52:22 PDT ---
Created an attachment (id=459)
updated patch

Thanks for running the test-suite.

The updated patch adds two changes:
- when the speculative type semantics fail, "dprogress" is also reset to its
original value, so the runDeferredSemantic does not think it should continue.
- when template instantiation fails, it is now also removed from the
module/class member list. DMD 2.032 just removes it from the list of template
instantiations.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=102



--- Comment #10 from Don <clugdbug@yahoo.com.au> 2009-09-19 12:32:08 PDT ---
(In reply to comment #9)
> Created an attachment (id=459) [details]
> updated patch
> 
> Thanks for running the test-suite.
> 
> The updated patch adds two changes:
> - when the speculative type semantics fail, "dprogress" is also reset to its
> original value, so the runDeferredSemantic does not think it should continue.
> - when template instantiation fails, it is now also removed from the
> module/class member list. DMD 2.032 just removes it from the list of template
> instantiations.

Now passes the full test suite. This is a candidate for best patch ever. I've never seen anything with the potential to fix so many bugs as once.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------