Bug 1533 – Crash unknown symbol with std.signals

Status
RESOLVED
Resolution
DUPLICATE
Severity
major
Priority
P2
Component
dmd
Product
D
Version
D1 (retired)
Platform
x86
OS
All
Creation time
2007-09-26T07:10:00Z
Last change time
2014-02-17T22:50:16Z
Keywords
ice-on-invalid-code, patch
Assigned to
bugzilla
Creator
regan

Comments

Comment #0 by regan — 2007-09-26T07:10:13Z
Crashes on compile: import std.c.windows.windows; import std.signals; class ChildProcesses { void foobar() { void delegate(int) retCodeCall; PHandle p; foo(); //trigger p.retCodeSignal.connect(retCodeCall); } class PHandle { mixin Signal!(int) retCodeSignal; } } Compile with "dmd file.d". Remove line marked trigger and there is no crash.
Comment #1 by matti.niemenmaa+dbugzilla — 2007-09-26T07:23:07Z
Confirmed on 1.021 as well. A shorter version: import std.signals; class ChildProcesses { void foobar() { foo(); //trigger this.retCodeSignal; } mixin Signal!(int) retCodeSignal; }
Comment #2 by wbaxter — 2007-09-26T12:00:35Z
The error message printed just before the compiler crashes is amusing: sigbug.d(7): Error: undefined identifier foo sigbug.d(7): Error: function expected before (), not foo of type int sigbug.d(236): function sigbug.ChildProcesses.foobar.Signal!(int)._dtor destruct ors only are for class definitions line 236.. of a 13 line program. But should an ice-on-invalid really be marked Severity:critical?
Comment #3 by matti.niemenmaa+dbugzilla — 2007-09-26T12:20:31Z
(In reply to comment #2) > The error message printed just before the compiler crashes is amusing: > > sigbug.d(7): Error: undefined identifier foo > sigbug.d(7): Error: function expected before (), not foo of type int > sigbug.d(236): function sigbug.ChildProcesses.foobar.Signal!(int)._dtor > destruct > ors only are for class definitions > > line 236.. of a 13 line program. The mixin pulls in a bunch of stuff. DMD isn't smart enough to point to the actual line where the code is, pointing only to the mixin-expanded code (which you can't even ever see since there's nothing like C compilers' -E). > But should an ice-on-invalid really be marked Severity:critical? I don't think so. Changing to major.
Comment #4 by thomas-dloop — 2007-09-30T05:00:05Z
The below condensed invalid code also triggers this ICE: # template T(){ # this(){ # } # # int dummy; # } # # class C{ # void foo(){ # bar(); # this.t.dummy = 1; # } # mixin T!() t; # } Added to DStress as http://dstress.kuehne.cn/run/t/this_16_A.d http://dstress.kuehne.cn/nocompile/t/this_16_B.d http://dstress.kuehne.cn/nocompile/t/this_16_C.d http://dstress.kuehne.cn/nocompile/t/this_16_D.d
Comment #5 by clugdbug — 2009-04-20T02:34:45Z
DMD2.028. func.c, line 954. Don't try to call the invariant if earlier errors have meant we don't have a 'this'. --------- // Postcondition invariant if (addPostInvariant()) { if (!ad) return; // <--- add this line Expression *e = NULL; if (isCtorDeclaration()){ // Call invariant directly only if it exists --------
Comment #6 by clugdbug — 2009-04-20T04:09:49Z
Same as bug 642, case 14G. *** This bug has been marked as a duplicate of 642 ***