[Issue 1079] gdb: Dwarf Error: Cannot find DIE at 0xb705 referenced from DIE at 0x250

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=1079



--- Comment #17 from Bernard Helyer  2010-01-20 
21:17:42 PST ---
Compiling with `-gc` allows gdb to debug it (but not interact with AA or DAs,
of course). This is with a patched gdb, though. Perhaps the bug lies in the
patches? I have definitely had failures on larger projects with `-gc`, though,
so I suspect dmd still has problems with its DWARF output regardless.

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


[Issue 1079] gdb: Dwarf Error: Cannot find DIE at 0xb705 referenced from DIE at 0x250

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=1079



--- Comment #16 from Bernard Helyer  2010-01-20 
20:55:48 PST ---
Oh! The above were simply compiled like so:

dmd -g list.d
dmd -g nolist.d

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


[Issue 1079] gdb: Dwarf Error: Cannot find DIE at 0xb705 referenced from DIE at 0x250

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=1079



--- Comment #15 from Bernard Helyer  2010-01-20 
20:53:25 PST ---
This seems to have something to do with arrays (or manifests itself when they
are present):

  [test]$ cat nolist.d 
  void main()
  {
  int i = 0;

  i++;
  assert(i == 1);
  i++;
  assert(i == 2);
  i++;
  assert(i == 3);
  }

That debugs fine, while

[test]$ cat list.d 
void main()
{
int[] i = new int[1];

i[0]++;
assert(i[0] == 1);
i[0]++;
assert(i[0] == 2);
i[0]++;
assert(i[0] == 3);
}


debugging these:

[test]$ dgdb -q nolist
(gdb) break _Dmain
Breakpoint 1 at 0x80490aa: file nolist.d, line 1.
(gdb) run
Starting program: /home/bernard/src/dmd2/src/test/nolist 
[Thread debugging using libthread_db enabled]
[New Thread 0xb75c46d0 (LWP 27012)]
[Switching to Thread 0xb75c46d0 (LWP 27012)]

Breakpoint 1, D main () at nolist.d:3
3int i = 0;
Current language:  auto; currently d
(gdb) quit
The program is running.  Exit anyway? (y or n) y
[test]$ dgdb -q list
(gdb) break _Dmain
Die: DW_TAG_ (abbrev = 4, offset = 460)
has children: FALSE
attributes:
DW_AT_byte_size (DW_FORM_data1) constant: 8
DW_AT_type (DW_FORM_ref4) constant ref: 453 (adjusted)
Dwarf Error: Cannot find type of die [in module
/home/bernard/src/dmd2/src/test/list]
(gdb) quit
[test]$ gdb -q list
(gdb) break _Dmain
Die: DW_TAG_ (abbrev = 4, offset = 460)
has children: FALSE
attributes:
DW_AT_byte_size (DW_FORM_data1) constant: 8
DW_AT_type (DW_FORM_ref4) constant ref: 453 (adjusted)
Dwarf Error: Cannot find type of die [in module
/home/bernard/src/dmd2/src/test/list]




Where `dgdb` is a patch GDB 6.8 and `gdb` is the normal GDB that ships with
Jaunty. The `nolist` binary is debuggable with the stock GDB, too.

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


[Issue 3732] New: Not all COM interfaces inherit from IUnknown.

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3732

   Summary: Not all COM interfaces inherit from IUnknown.
   Product: D
   Version: 2.037
  Platform: x86
OS/Version: Windows
Status: NEW
  Severity: minor
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: burton-rad...@shaw.ca


--- Comment #0 from Burton Radons  2010-01-20 19:59:05 
PST ---
Well this is rude. It turns out some COM interfaces - I specifically know of
ID3D10Include
(http://msdn.microsoft.com/en-us/library/ee419311%28VS.85%29.aspx) - do not
inherit from IUnknown. Since inheritance from IUnknown is how DMD applies its
magic, it means that such interfaces cannot be implemented directly from D.

It would seem preferable to have a "pragma (COM)" or "pragma (com)" attribute
to apply to an interface to cause it and its descendants to be understood to be
COM participants than to inherit from IUnknown, which seems an outdated
commonality, unfortunately.

The justification from Microsoft's side seems to be that ID3D10Include objects
should be lightweight, so removing IUnknown allows them to be stack objects
since it's impossible for anyone to retain a living reference to them after
returning.

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


[Issue 3674] forward reference error with multiple overloads with same name

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3674



--- Comment #4 from Rainer Schuetze  2010-01-20 14:48:34 
PST ---
The current revision (342) now shows a different error, even with a slightly
reduced test case:

public class IQGraphicsItem
{
public QGraphicsObject toGraphicsObject();
public QGraphicsObject toGraphicsObject() const;
}

public abstract class QGraphicsObject : IQGraphicsItem
{
public final QGraphicsObject toGraphicsObject() { return null; }  // Line
10
public final QGraphicsObject toGraphicsObject() const { return null; } //
Line 11
}

and causes
test.d(11): Error: function test.QGraphicsObject.toGraphicsObject cannot
override final function test.QGraphicsObject.toGraphicsObject

This is what happens:
dmd searches its vtbl for a covariant function that is overridden by
"toGraphicsObject() const". The rules in Type::covariant() state, that it's ok
to match the non-const version of toGraphicsObject(). This triggers two
problems:

- The first match is taken, not the best.
- The class's vtbl is searched, not the vtbl of the base class. As the
non-const version of the function is already matched and placed into the vtbl,
the function type might have changed due to covariance. In this case, it is
final now.

Here's a patch to solve both issues:

Index: func.c
===
--- func.c(revision 342)
+++ func.c(working copy)
@@ -382,7 +382,7 @@
 }

 // Find index of existing function in vtbl[] to override
-vi = findVtblIndex(&cd->vtbl, cd->baseClass ? cd->baseClass->vtbl.dim :
0);
+vi = cd->baseClass ? findVtblIndex(&cd->baseClass->vtbl,
cd->baseClass->vtbl.dim) : -1;
 switch (vi)
 {
 case -1:
@@ -426,7 +426,7 @@
 return;

 default:
-{   FuncDeclaration *fdv = (FuncDeclaration *)cd->vtbl.data[vi];
+{   FuncDeclaration *fdv = (FuncDeclaration
*)cd->baseClass->vtbl.data[vi];
 // This function is covariant with fdv
 if (fdv->isFinal())
 error("cannot override final function %s", fdv->toPrettyChars());
@@ -1689,11 +1689,15 @@

 int FuncDeclaration::findVtblIndex(Array *vtbl, int dim)
 {
+FuncDeclaration *mismatch = 0;
+int bestvi = -1;
 for (int vi = 0; vi < dim; vi++)
 {
 FuncDeclaration *fdv = ((Dsymbol *)vtbl->data[vi])->isFuncDeclaration();
 if (fdv && fdv->ident == ident)
 {
+if (type->equals(fdv->type))
+return vi;
 int cov = type->covariant(fdv->type);
 //printf("\tbaseclass cov = %d\n", cov);
 switch (cov)
@@ -1702,14 +1706,15 @@
 break;

 case 1:
-return vi;
+bestvi = vi; // covariant, but not identical
+break;

 case 2:
+if(!mismatch) // give a second chance to find exact match
+mismatch = fdv;
 //type->print();
 //fdv->type->print();
 //printf("%s %s\n", type->deco, fdv->type->deco);
-error("of type %s overrides but is not covariant with %s of type
%s",
-type->toChars(), fdv->toPrettyChars(), fdv->type->toChars());
 break;

 case 3:
@@ -1720,7 +1725,10 @@
 }
 }
 }
-return -1;
+if(bestvi < 0 && mismatch)
+error("of type %s overrides but is not covariant with %s of type %s",
+type->toChars(), mismatch->toPrettyChars(),
mismatch->type->toChars());
+return bestvi;
 }

 /

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


[Issue 3725] Add united type to standard library

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3725



--- Comment #2 from BCS  2010-01-20 13:01:21 PST 
---
(In reply to comment #1)
> Is your type support fractional exponents of units?

yes. the unittest at the bottom uses "Stress Intensity", an alias for
pressue*sqrt(distance)

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


[Issue 3730] Struct's explicit constructor can't initialize global variables

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3730


Don  changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au


--- Comment #1 from Don  2010-01-20 12:55:03 PST ---
This works for me in DMD2.039 Windows svn 342. (Are you sure you're not using
2.038?)

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


[Issue 3731] New: Immutable class may be changed when inherits from mutable parent

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3731

   Summary: Immutable class may be changed when inherits from
mutable parent
   Product: D
   Version: 2.039
  Platform: x86
OS/Version: Windows
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: tomeks...@gmail.com


--- Comment #0 from Tomasz Sowiński  2010-01-20 12:44:48 
PST ---
This merrily compiles:

class Zmienna {
int a;
this(int a) {
this.a = a;
}
}

immutable class Stala : Zmienna {
this(int a) {
super(a);
}
}

void main() {
auto st = new Stala(5);
Zmienna zm = st;
zm.a = 666;
//  st.a = 666; // fails
assert (st.a == 666);
}


The above shows that an immutable class shouldn't be allowed to derive from
mutable classes. Unfortunately it won't work because Object is not (and can't
be) immutable. Not sure how to bite this one, perhaps make an opt out that says
mutable parents with no fields are OK? Or an exception only for Object?

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


[Issue 3730] New: Struct's explicit constructor can't initialize global variables

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3730

   Summary: Struct's explicit constructor can't initialize global
variables
   Product: D
   Version: 2.039
  Platform: x86
OS/Version: Windows
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: tomeks...@gmail.com


--- Comment #0 from Tomasz Sowiński  2010-01-20 12:20:09 
PST ---
Test case:

struct S {
int a;
this(int a) {
this.a = a;
}
static immutable S es = S(3);
}

Compiler output (message printed twice in original):
test.d|9|Error: cannot evaluate ((S __ctmp516;
test.d|9|Error: cannot evaluate ((S __ctmp516;

Don't know if that should compile but surely the message could be more
appealing.

static this() may be used as a workaround for this bug.

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


[Issue 3723] Regression: forward referenced enum

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3723


Don  changed:

   What|Removed |Added

   Keywords||patch


--- Comment #2 from Don  2010-01-20 11:31:37 PST ---
I've fixed this by changing the code in mtype.c, line 5984:

Type *TypeEnum::toBasetype()
{
if (sym->scope)
{
-sym->semantic(NULL);// attempt to resolve forward reference
+sym->trySemantic(NULL);// attempt to resolve forward reference
}

and adding this code to enum.c:

void EnumDeclaration::trySemantic(Scope *sc)
{
unsigned errors = global.errors;
global.gag++;
DsymbolTable *savetable = symtab;
semantic(sc);
global.gag--;
if (errors != global.errors)
{   
global.errors = errors;
symtab = savetable;
}
}

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


[Issue 3659] Too much exegesis on opEquals

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3659


Tomasz Sowiński  changed:

   What|Removed |Added

 CC||tomeks...@gmail.com


--- Comment #5 from Tomasz Sowiński  2010-01-20 11:27:48 
PST ---
Another quirk caused by forcing const in opEquals is bug 3729.

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


[Issue 3729] New: Can't define opEquals for immutable types

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3729

   Summary: Can't define opEquals for immutable types
   Product: D
   Version: 2.039
  Platform: x86
OS/Version: Windows
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: tomeks...@gmail.com


--- Comment #0 from Tomasz Sowiński  2010-01-20 11:26:17 
PST ---
immutable struct S {
bool opEquals(ref S s) { ... }
}

The above doesn't compile, as the parameter is required to be const and the
function to be const as well and it's immutable in both cases. Since an
immmutable type can't be less than immutable such a requirement is pointless.

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


[Issue 3728] getOverloads and identifier traits

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3728



--- Comment #4 from Max Samukha  2010-01-20 11:07:36 
PST ---
When implementing isStaticFunction, please make sure it returns true for any
function that doesn't require a context pointer (even if there is no explicit
STCstatic).

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


[Issue 3726] Regression: ICE(mangle.c 81): struct forward reference with static this

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3726


Don  changed:

   What|Removed |Added

Summary|Assertion failure: 'fd &&   |Regression: ICE(mangle.c
   |fd->inferRetType' on line   |81): struct forward
   |81 in file 'mangle.c'   |reference with static this


--- Comment #2 from Don  2010-01-20 11:00:42 PST ---
Reduced test case:
---
struct Bug3276A {
   Bug3726B  xxx;
   static this () { }
}

struct Bug3726B {}

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


[Issue 3728] getOverloads and identifier traits

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3728


Eldar Insafutdinov  changed:

   What|Removed |Added

 CC||e.insafutdi...@gmail.com


--- Comment #3 from Eldar Insafutdinov  2010-01-20 
10:08:35 PST ---
(In reply to comment #2)
> Given the size and visibility of Qt, I think it's fair to leave this as
> critical. I also voted for it :o).

Yeah, it actually is a blocker as you cannot use unpatched dmd for qtd. Thanks
for voting. In fact this functionality was requested in the bug report 2855.
The reason why we replace getVirtualFunctions with getOverloads rather than add
the new one is because the functionality that the former provides could easily
be achieved by filtering out the ouput of the latter with isVirtualFunction
trait. That way we don't bloat __traits.

The mentioned patch also provides isStaticFunction trait which we will
eventually need.

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


[Issue 3728] getOverloads and identifier traits

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3728


Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@metalanguage.com
   Severity|enhancement |critical


--- Comment #2 from Andrei Alexandrescu  2010-01-20 
09:39:09 PST ---
Given the size and visibility of Qt, I think it's fair to leave this as
critical. I also voted for it :o).

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


[Issue 3728] getOverloads and identifier traits

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3728


Max Samukha  changed:

   What|Removed |Added

   Severity|critical|enhancement


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


[Issue 3728] getOverloads and identifier traits

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3728



--- Comment #1 from Max Samukha  2010-01-20 09:09:47 
PST ---
Created an attachment (id=553)
getOverloads, identifier traits

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


[Issue 3728] New: getOverloads and identifier traits

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3728

   Summary: getOverloads and identifier traits
   Product: D
   Version: unspecified
  Platform: Other
OS/Version: Windows
Status: NEW
  Severity: critical
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: samu...@voliacable.com


--- Comment #0 from Max Samukha  2010-01-20 09:06:49 
PST ---
For QtD, we need to get overloads of any function at compile time, not only
virtuals. Currently we are using a seemingly working dmd modified with the
patch attached. The patch also adds an 'identifier' trait, which allows to get
symbol identifiers without parsing the value of stringof.

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


[Issue 3725] Add united type to standard library

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3725


Witold Baryluk  changed:

   What|Removed |Added

 CC||bary...@smp.if.uj.edu.pl


--- Comment #1 from Witold Baryluk  2010-01-20 
08:00:35 PST ---
Is your type support fractional exponents of units?

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


[Issue 3727] New: lots of "deffering SomeStructName" messages when compiling

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3727

   Summary: lots of "deffering SomeStructName" messages when
compiling
   Product: D
   Version: 2.039
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bary...@smp.if.uj.edu.pl


--- Comment #0 from Witold Baryluk  2010-01-20 
07:27:32 PST ---
This doesn't happen in 2.037:

# dmd2 .
...
deferring SDL_KeyboardEvent
deferring SDL_KeyboardEvent
deferring SDL_KeyboardEvent
deferring SDL_KeyboardEvent
deferring SDL_KeyboardEvent
deferring SDL_KeyboardEvent
deferring SDL_KeyboardEvent
deferring SDL_KeyboardEvent
deferring SDL_KeyboardEvent
deferring SDL_KeyboardEvent
deferring SDL_KeyboardEvent
deferring SDL_KeyboardEvent
deferring SDL_KeyboardEvent
deferring SDL_Event
deferring SDL_KeyboardEvent
deferring SDL_Event
deferring SDL_KeyboardEvent
deferring SDL_Event
deferring SDL_KeyboardEvent
deferring SDL_Event
deferring SDL_KeyboardEvent
deferring SDL_Event
deferring SDL_KeyboardEvent
deferring SDL_Event
deferring SDL_KeyboardEvent
deferring SDL_Event
deferring SDL_KeyboardEvent
deferring SDL_Event
deferring SDL_Cursor
deferring SDL_Cursor
deferring SDL_Cursor
deferring SDL_Cursor
deferring SDL_Cursor
deferring SDL_Cursor
deferring SDL_Cursor
deferring SDL_Cursor
deferring SDL_Cursor
deferring SDL_Cursor
deferring SDL_Cursor
deferring SDL_Cursor
deferring SDL_Cursor
  ...
#

It looks like some reminescences of debuging new "forward structs" code:
bug3663: struct forward reference regresssion
bug3664: struct forward declaration causes enum to conflict with itself

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


[Issue 3687] Array operation "slice times scalar" tramples over memory

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3687



--- Comment #5 from Don  2010-01-20 06:56:52 PST ---
The original test case passes on D2, but here's a test case which fails on both
D1 and D2.
--
void main()
{
float[66] array;
array[] = 0;
array[64] = 42;
array[65] = 43;
array[0..64] *= 2f;
assert(array[65] == 43);
assert(array[64] == 42);
}
--

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


[Issue 2510] provide a template instantiation backtrace when compile fails in a template

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2510


Don  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #5 from Don  2010-01-20 00:22:12 PST ---
Fixed DMD1.054 and 2.038.

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


[Issue 3726] Assertion failure: 'fd && fd->inferRetType' on line 81 in file 'mangle.c'

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3726


Don  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||clugd...@yahoo.com.au
Version|unspecified |1.00


--- Comment #1 from Don  2010-01-19 23:59:21 PST ---
This looks similar to bug 2080; quite likely to be a duplicate.

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


[Issue 3726] New: Assertion failure: 'fd && fd->inferRetType' on line 81 in file 'mangle.c'

2010-01-20 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3726

   Summary: Assertion failure: 'fd && fd->inferRetType' on line 81
in file 'mangle.c'
   Product: D
   Version: unspecified
  Platform: x86
OS/Version: Windows
Status: NEW
  Severity: blocker
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: chang...@gmail.com


--- Comment #0 from changlon  2010-01-19 23:55:37 PST ---
Created an attachment (id=552)
build tango error width dmd1 r342 svn version on windows.

i build dmd1 r342 on window. 

use it build tango throw this:` Assertion failure: 'fd && fd->inferRetType' on
line 81 in file 'mangle.c' `

display a message box with text : `abnormal program termination`

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