[Issue 4781] Segfault(mtype.c) with forward referenced typeof and .init

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4781


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #2 from Don clugd...@yahoo.com.au 2010-11-15 00:03:25 PST ---
Fixed svn 755.

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


[Issue 2080] ICE(mangle.c) alias corrupts type inference of static variables

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2080


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #8 from Don clugd...@yahoo.com.au 2010-11-15 00:04:15 PST ---
Fixed svn 755.

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


[Issue 3493] Segfault(cast.c) Forward reference with type inference, D1 only.

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3493


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


--- Comment #5 from Don clugd...@yahoo.com.au 2010-11-15 00:16:29 PST ---
Fixed dmd 1.064.

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


[Issue 3293] ICE(expression.c) recursive alias template parameters

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3293


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #6 from Don clugd...@yahoo.com.au 2010-11-15 00:17:40 PST ---
Fixed DMD2.047.

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


[Issue 4615] dmdscript no longer compiles

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4615


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||clugd...@yahoo.com.au
 Resolution||WORKSFORME


--- Comment #1 from Don clugd...@yahoo.com.au 2010-11-15 00:38:00 PST ---
I tried DMD1.060, 1.063, 1.065, and the latest DMD1 from svn, all on WinXP.
They all work.
Sounds to me as though you have a problem with your paths. Or maybe you have a
rogue lexer.di file somewhere.

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


[Issue 4484] Warning for unreachable code in scope statements is too confusing

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4484


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

   Keywords||rejects-valid
   Severity|enhancement |normal


--- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2010-11-15 01:56:17 
PST ---
scope(failure) assert(0);

would be another nice thing to be able to do - particularly when trying to
ensure that a function is nothrow (but it results in the error about a
statement being unreachable). Putting the whole function in a try-catch block
to do that is definitely uglier.

In any case, I think that I'm promoting this to a normal bug rather than an
enhancement request. The fact that scope statements translate into try-catch
blocks is an implementation detail which shouldn't leak into error messages.
While it makes good sense to implement scope that way, I'm not sure that
there's anything really requiring that it be implemented that way, and the
errors about unreachable code make various useful constructs illegal when they
really shouldn't be.

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


[Issue 3463] Integrate Precise Heap Scanning Into the GC

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #83 from bearophile_h...@eml.cc 2010-11-15 04:43:23 PST ---
(In reply to comment #82)

 Anyway, unfortunately DMD development model still sucks, it sucks much less
 than... let's say 2 years ago, but...

Walter is willing to slowly improve his practices. Do you have a list of
suggestions? If you show this list on the main D newsgroup he might pick
something from it.

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


[Issue 3463] Integrate Precise Heap Scanning Into the GC

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #84 from Leandro Lucarella llu...@gmail.com 2010-11-15 04:47:48 
PST ---
(In reply to comment #83)
 (In reply to comment #82)
 
  Anyway, unfortunately DMD development model still sucks, it sucks much less
  than... let's say 2 years ago, but...
 
 Walter is willing to slowly improve his practices. Do you have a list of
 suggestions? If you show this list on the main D newsgroup he might pick
 something from it.

I (and others) already suggested him how to improve things, a few really basic
examples that come to my mind right now:

* Tag releases in svn
* Give feedback to people wanting to contribute

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


[Issue 3749] cannot evaluate yl2x (log) and exp functions at compile time

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3749



--- Comment #8 from simon s.d.hamm...@googlemail.com 2010-11-15 05:27:01 PST 
---
Created an attachment (id=811)
PATCH against rev 755 add support for yl2x, yl2xp1

Implements yl2x, yl2xp1 as builtins for DMC, VisualStudio.
Needs implementation for GCC

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


[Issue 5205] D runtime duplication in zip

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5205


Steven Schveighoffer schvei...@yahoo.com changed:

   What|Removed |Added

 CC||ibuc...@ubuntu.com


--- Comment #4 from Steven Schveighoffer schvei...@yahoo.com 2010-11-15 
08:06:40 PST ---
*** Issue 5208 has been marked as a duplicate of this issue. ***

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


[Issue 5208] Inconsistency between src and import druntime files.

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5208


Steven Schveighoffer schvei...@yahoo.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution||DUPLICATE


--- Comment #2 from Steven Schveighoffer schvei...@yahoo.com 2010-11-15 
08:06:39 PST ---
Hm... someone *just* reported this bug :)

*** This issue has been marked as a duplicate of issue 5205 ***

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


[Issue 3463] Integrate Precise Heap Scanning Into the GC

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #85 from bearophile_h...@eml.cc 2010-11-15 09:33:56 PST ---
(In reply to comment #84)

 I (and others) already suggested him how to improve things,

Keep suggesting those things. Sometimes you have to say something five times to
Walter.


 * Tag releases in svn

Explain him why this is useful.


 * Give feedback to people wanting to contribute

Maybe he doesn't fully understand why contributions from other people are
important. Showing him some examples is useful.

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


[Issue 3463] Integrate Precise Heap Scanning Into the GC

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #86 from Leandro Lucarella llu...@gmail.com 2010-11-15 09:44:18 
PST ---
(In reply to comment #85)
 (In reply to comment #84)
 
  I (and others) already suggested him how to improve things,
 
 Keep suggesting those things. Sometimes you have to say something five times 
 to
 Walter.
 
 
  * Tag releases in svn
 
 Explain him why this is useful.
 
 
  * Give feedback to people wanting to contribute
 
 Maybe he doesn't fully understand why contributions from other people are
 important. Showing him some examples is useful.

This is getting a little off-topic here, but I think I'll focus on other
projects, is too much effort. I agree that Walter has improved a little, but
the ratio results/efforts is *really* low still, and it doesn't worth it for me
any more. I hate sounding like a broken record...

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


[Issue 5093] improve error for importing std.c.windows.windows

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5093



--- Comment #3 from simon s.d.hamm...@googlemail.com 2010-11-15 11:03:49 PST 
---
Created an attachment (id=812)
PATCH against rev 755: implement a module import backtrace for static assert

Implements a module import back-trace for static asserts.

This ought to be implemented for non-static asserts as well,
but that probably involves mucking about in the back end
and I can't be bothered diving into that at the mo.

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


[Issue 5090] ICE(todt.c) struct literal initializing zero length array

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5090


simon s.d.hamm...@googlemail.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|nob...@puremagic.com|s.d.hamm...@googlemail.com


--- Comment #2 from simon s.d.hamm...@googlemail.com 2010-11-15 11:33:15 PST 
---
Created an attachment (id=813)
PATCH against rev 755: fix crash in first case

Fixed:

A a = A(0); // Fails, compiler aborts

by issuing error msg.

I'll dig a bit more into fixing the second case, that should be an error as
way.

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


[Issue 5090] ICE(todt.c) struct literal initializing zero length array

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5090



--- Comment #3 from Iain Buclaw ibuc...@ubuntu.com 2010-11-15 12:11:09 PST ---
Just under the duplicate union error is where to look iirc.

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


[Issue 4837] ICE(constfold.c) CTFE with =

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4837


simon s.d.hamm...@googlemail.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|nob...@puremagic.com|s.d.hamm...@googlemail.com


--- Comment #1 from simon s.d.hamm...@googlemail.com 2010-11-15 12:24:38 PST 
---
Created an attachment (id=814)
PATCH against rev 755: remove superfluous asserts

fixed, no idea why asserts where placed in there.
unsigned shifting of 8 ^ 16 bit values seems perfectly reasonable.

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


[Issue 4837] ICE(constfold.c) CTFE with =

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=4837



--- Comment #2 from Don clugd...@yahoo.com.au 2010-11-15 12:39:53 PST ---
(In reply to comment #1)
 Created an attachment (id=814) [details]
 PATCH against rev 755: remove superfluous asserts
 
 fixed, no idea why asserts where placed in there.
 unsigned shifting of 8 ^ 16 bit values seems perfectly reasonable.

The problem is that the code there gives different results to what happens in
all other situations. See bug 2809. 
As far as I can tell,  is a broken concept. Andrei and I tried to get it
removed from the language before publication of TDPL, but we failed.

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


Re: [Issue 5093] improve error for importing std.c.windows.windows

2010-11-15 Thread Don

d-bugm...@puremagic.com wrote:

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



--- Comment #3 from simon s.d.hamm...@googlemail.com 2010-11-15 11:03:49 PST 
---
Created an attachment (id=812)
PATCH against rev 755: implement a module import backtrace for static assert

Implements a module import back-trace for static asserts.

This ought to be implemented for non-static asserts as well,
but that probably involves mucking about in the back end
and I can't be bothered diving into that at the mo.

Cool! In cases where it's imported from inside a static if, this is 
fantastic.
Ideally, it would only do the module trace starting from the last 
instantiated template. (Which would mean that in many cases, it wouldn't 
appear at all). I think this should be applied to all template 
instantiation back traces.


Re: [Issue 5093] improve error for importing std.c.windows.windows

2010-11-15 Thread Don

Jonathan M Davis wrote:

On Monday 15 November 2010 12:49:05 Don wrote:

d-bugm...@puremagic.com wrote:

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



--- Comment #3 from simon s.d.hamm...@googlemail.com 2010-11-15
11:03:49 PST --- Created an attachment (id=812)
PATCH against rev 755: implement a module import backtrace for static
assert

Implements a module import back-trace for static asserts.

This ought to be implemented for non-static asserts as well,
but that probably involves mucking about in the back end
and I can't be bothered diving into that at the mo.

Cool! In cases where it's imported from inside a static if, this is
fantastic.
Ideally, it would only do the module trace starting from the last
instantiated template. (Which would mean that in many cases, it wouldn't
appear at all). I think this should be applied to all template
instantiation back traces.


I expect that you meant to post a comment to the bug rather than post on the bug 
list...


- Jonathan M Davis

You expect wrong.


[Issue 5212] Safer typesafe variadics

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5212



--- Comment #5 from bearophile_h...@eml.cc 2010-11-15 14:11:15 PST ---
Extra note:

It's a problem of perception: typesafe variadic arguments don't look like
normal function arguments that you know are usually on the stack, they look
like dynamic arrays, and in D most dynamic arrays are allocated on the heap
(it's easy and useful to take a dynamic-array-slice of a stack allocated array,
but in this case the code shows that the slice doesn't contain heap data).

If your function has a signature similar to this one:

void foo(int[3] arr...) {

It's not too much hard to think that 'arr' is on the stack. But dynamic arrays
don't give that image:

void foo(int[] arr...) {

This is why I think it's better for the compiler to test if the arr data is on
the stack, and dup it otherwise (unless a 'scope' is present, in this case both
the test and allocation aren't present).

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


[Issue 2809] Wrong constant folding for unsigned shift

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2809


simon s.d.hamm...@googlemail.com changed:

   What|Removed |Added

 CC||s.d.hamm...@googlemail.com


--- Comment #3 from simon s.d.hamm...@googlemail.com 2010-11-15 14:29:19 PST 
---
Mr Bs test case is wrong:

static assert((cast(short)-1  1) == int.max);

should be:

static assert((cast(short)-1  1) == short.max);

unsigned right shift is perfectly well defined,
though giving it it's own operator seems like overkill.

I think it would be better as a function in std.intrinsic.

You aren't going to use unsigned shift unless you know what you doing and care
about performance.

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


[Issue 2809] Wrong constant folding for unsigned shift

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2809



--- Comment #4 from Don clugd...@yahoo.com.au 2010-11-15 15:06:34 PST ---
(In reply to comment #3)
 Mr Bs test case is wrong:
 
 static assert((cast(short)-1  1) == int.max);
 
 should be:
 
 static assert((cast(short)-1  1) == short.max);

Not so. You might be thinking of this, which _is_ true:
static assert((cast(short)-1  cast(short)1) == short.max);

The problem is that  interacts badly with implicit type conversions.
With every other operator,  typeof(short OP int) == int.

Possible solutions are:
(a) special case for 
(b) disallow  for types smaller than int
(c) drop it from the language
Personally I think (c) is the only option that makes sense.

 unsigned right shift is perfectly well defined,
 though giving it it's own operator seems like overkill.
 
 I think it would be better as a function in std.intrinsic.

You don't need it at all. Just cast to unsigned, then .
 is a ridiculous operator.

 You aren't going to use unsigned shift unless you know what you doing and care
 about performance.

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


[Issue 5218] Can't implicitly convert from abcw to wchar[3]

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5218


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

   Keywords||patch


--- Comment #1 from Don clugd...@yahoo.com.au 2010-11-15 15:36:06 PST ---
PATCH: This is because abcw and abcd are committed types. If the type is
committed, implicit conversions are not performed at all. But this is wrong:
they should still allow const/immutable conversions.



Index: cast.c
===
--- cast.c(revision 755)
+++ cast.c(working copy)
@@ -449,8 +449,6 @@
 printf(StringExp::implicitConvTo(this=%s, committed=%d, type=%s,
t=%s)\n,
 toChars(), committed, type-toChars(), t-toChars());
 #endif
-if (!committed)
-{
 if (!committed  t-ty == Tpointer  t-nextOf()-ty == Tvoid)
 {
 return MATCHnomatch;
@@ -471,7 +469,8 @@
 ((TypeSArray *)t)-dim-toInteger())
 return MATCHnomatch;
 TY tynto = t-nextOf()-ty;
-if (tynto == Tchar || tynto == Twchar || tynto ==
Tdchar)
+if (tynto == tyn) return MATCHexact;
+if (!committed  (tynto == Tchar || tynto == Twchar
|| tynto == Tdchar))
 return MATCHexact;
 }
 else if (type-ty == Tarray)
@@ -480,7 +479,8 @@
 ((TypeSArray *)t)-dim-toInteger())
 return MATCHnomatch;
 TY tynto = t-nextOf()-ty;
-if (tynto == Tchar || tynto == Twchar || tynto ==
Tdchar)
+if (tynto == tyn) return MATCHexact;
+if (!committed  (tynto == Tchar || tynto == Twchar
|| tynto == Tdchar))
 return MATCHexact;
 }
 case Tarray:
@@ -497,13 +497,13 @@
 case Tchar:
 case Twchar:
 case Tdchar:
-return m;
+if (!committed)
+return m;
 }
 break;
 }
 }
 }
-}
 return Expression::implicitConvTo(t);
 #if 0
 m = (MATCH)type-implicitConvTo(t);

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


Re: [Issue 5093] improve error for importing std.c.windows.windows

2010-11-15 Thread Jonathan M Davis
On Monday, November 15, 2010 13:59:10 Don wrote:
 Jonathan M Davis wrote:
  On Monday 15 November 2010 12:49:05 Don wrote:
  d-bugm...@puremagic.com wrote:
  http://d.puremagic.com/issues/show_bug.cgi?id=5093
  
  
  
  --- Comment #3 from simon s.d.hamm...@googlemail.com 2010-11-15
  11:03:49 PST --- Created an attachment (id=812)
  PATCH against rev 755: implement a module import backtrace for static
  assert
  
  Implements a module import back-trace for static asserts.
  
  This ought to be implemented for non-static asserts as well,
  but that probably involves mucking about in the back end
  and I can't be bothered diving into that at the mo.
  
  Cool! In cases where it's imported from inside a static if, this is
  fantastic.
  Ideally, it would only do the module trace starting from the last
  instantiated template. (Which would mean that in many cases, it wouldn't
  appear at all). I think this should be applied to all template
  instantiation back traces.
  
  I expect that you meant to post a comment to the bug rather than post on
  the bug list...
  
  - Jonathan M Davis
 
 You expect wrong.

Okay. Sorry. It's just that normally no one posts directly to the list and any 
comments posted directly to the list probably won't get seen in the long run, 
since people will generally look at the bug reports directly.

- Jonathan M Davis


[Issue 5220] Make std.conv.ConvError an Exception instead of an Error

2010-11-15 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5220



--- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2010-11-15 21:07:45 
PST ---
As noted by dsimcha on Phobos list, ConvError should be left as a deprecated
alias to ConvException for a few releases to mitigate code breakage.

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