Ticket #14 (new defect)

Opened 2 years ago

Last modified 2 years ago

Template errors on Mac OS X

Reported by: afb Assigned to: somebody
Priority: major Milestone:
Component: TioPort Version:
Keywords: Cc:

Description (Last modified by keinfarbton)

Compilation of dejavu fails, unless giving the -fall-sources option to GDC:

../dejavu/dejavu/lang/StringBuffer.d:84: Error: forward reference to 'JArrayT!(wchar)'

../dejavu/dejavu/io/OutputStream.d:25: Error: forward reference to 'JArrayT!(byte)'

../dejavu/dejavu/lang/String.d:75: Error: forward reference to 'JArrayT!(wchar)'

And so on... Unfortunately, the -fall-sources option makes GDC *very* slow. :-( (as in: it now takes minutes to compile, where it takes seconds with DMD...)

-fall-sources

For each source file on the command line, semantically process each file preceding it. Use this if compilation errors occur due to complicated circular module references. This will slow compilation noticeably.

Change History

04/12/07 13:11:11 changed by keinfarbton

Hm, I think this is a compiler bug. A forward reference is AFAIK always a compiler bug. DMD 1.011 is the only compiler that i succufully compiled all SWT, so perhaps a GDC update to 1.011 is needed to compile this without errors.

It interesting, GDC has a workaround for such problems :)

04/12/07 13:50:12 changed by afb

If you think *that's* interesting, you should see the hacks for Mac OS X 10.3... :-)

-femit-templates[=full|private|none|auto]

Controls whether or not template code is emitted.

full Emit templates, expecting multiple copies to be merged by

the linker.

private

Emit templates, but make them private to the translation unit. The executable will have multiple copies of code and data.

none Do not emit templates at all.

auto For targets that support templates, the "full" mode is

used. Otherwise, the "private" mode is used.

Going with the half-an-hour compiles for now. Next I'll be using punch cards. :-)

(follow-up: ↓ 4 ) 04/14/07 04:00:54 changed by afb

A very unfortunate side-effect is that the compiler gets very confused about symbols with similarly sounding names, especially when not pre-declared or appearing in the preferred order...

For instance, this code: (from Control.d) 

    public org.eclipse.swt.graphics.Point.Point computeSize( int wHint, int hHint ){
        return computeSize( wHint, hHint, true);
    }

    public org.eclipse.swt.graphics.Point.Point computeSize( int wHint, int hHint, bool changed ){
        ...
    }

It ends up crashing, because it calls the wrong function: 

#0  0x00000000 in ?? ()
#1  0x003e8995 in org.eclipse.swt.widgets.Composite.Composite.computeSize() (this=@0x28da800, wHint=-1, hHint=-1, par_changed=true) at gen.d/org/eclipse/swt/widgets/Composite.d:203
#2  0x003f18d6 in org.eclipse.swt.widgets.Control.Control.computeSize() (this=@0x28da800, wHint=-1, hHint=-1) at gen.d/org/eclipse/swt/widgets/Control.d:291

(in reply to: ↑ 3 ) 04/14/07 04:34:00 changed by keinfarbton

  • description changed.

Replying to afb:

A very unfortunate side-effect is that the compiler gets very confused about symbols with similarly sounding names, especially when not pre-declared or appearing in the preferred order... For instance, this code: (from Control.d) {{{ public org.eclipse.swt.graphics.Point.Point computeSize( int wHint, int hHint ){ return computeSize( wHint, hHint, true); } public org.eclipse.swt.graphics.Point.Point computeSize( int wHint, int hHint, bool changed ){ ... } }}} It ends up crashing, because it calls the wrong function: {{{ #0 0x00000000 in ?? () #1 0x003e8995 in org.eclipse.swt.widgets.Composite.Composite.computeSize() (this=@0x28da800, wHint=-1, hHint=-1, par_changed=true) at gen.d/org/eclipse/swt/widgets/Composite.d:203 #2 0x003f18d6 in org.eclipse.swt.widgets.Control.Control.computeSize() (this=@0x28da800, wHint=-1, hHint=-1) at gen.d/org/eclipse/swt/widgets/Control.d:291 }}}

04/14/07 04:40:30 changed by keinfarbton

  • description changed.

If i understand you correctly, all this is only a compiler bug? There is no neeed to change something in TioPort or the generated sources.

04/14/07 06:56:23 changed by afb

I'm playing with workarounds, like replacing "computeSize" with org.eclipse.swt.widgets.Control.Control.computeSize

It's definitely a compiler workaround/difference, so it might be automatically closed when GDC 0.24 arrives. Or not, and then you need workarounds...

04/15/07 14:01:38 changed by afb

This issue turns out to be a show-stopper, unfortunately. Even if you can play whack-a-mole with the linker errors and get it to compile, it will still misbehave at runtime and call the wrong functions with the wrong type of objects - usually causing a null derefence sooner rather than later...

For instance, it crashes here: (gen.d/org/eclipse/swt/widgets/Composite.d:808) 

    public void updateLayout( bool all ){
        org.eclipse.swt.widgets.Composite.Composite parent = findDeferredControl;
        if (parent !is null ) {
            parent.state |= LAYOUT_CHILD;
            return ;
        }
        if ((state & LAYOUT_NEEDED) !is 0 ) {
            bool var_changed = (state & LAYOUT_CHANGED) !is 0;
            state &= (~(LAYOUT_NEEDED | LAYOUT_CHANGED));
            if (fld_layout !is null) // <-- inserted this test, just to make sure
            fld_layout.layout( this, var_changed); // <-- this line jumps to null
        }

Even if it's not all the same bug, this makes tioport's swt rather unworkable with GDC ?