[Issue 5220] Make std.conv.ConvError an Exception instead of an Error
http://d.puremagic.com/issues/show_bug.cgi?id=5220 --- Comment #1 from Jonathan M Davis 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: ---
[Issue 5220] New: Make std.conv.ConvError an Exception instead of an Error
http://d.puremagic.com/issues/show_bug.cgi?id=5220 Summary: Make std.conv.ConvError an Exception instead of an Error Product: D Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis 2010-11-15 21:04:58 PST --- std.conv.ConvError is an Error which makes it so that you can't catch it (unless you're willing to catch Errors, which you're not supposed to do). It should be an Exception so that it can be caught and handled in cases of failure rather than taking the whole program down with it just because to!() failed. Presumably, it should be renamed to ConvException as well. -- 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
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 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 5218] Can't implicitly convert from "abc"w to wchar[3]
http://d.puremagic.com/issues/show_bug.cgi?id=5218 Don changed: What|Removed |Added Keywords||patch --- Comment #1 from Don 2010-11-15 15:36:06 PST --- PATCH: This is because "abc"w and "abc"d 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: ---
[Issue 2809] Wrong constant folding for unsigned shift
http://d.puremagic.com/issues/show_bug.cgi?id=2809 --- Comment #4 from Don 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 2809] Wrong constant folding for unsigned shift
http://d.puremagic.com/issues/show_bug.cgi?id=2809 simon changed: What|Removed |Added CC||s.d.hamm...@googlemail.com --- Comment #3 from simon 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 5212] Safer typesafe variadics
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: ---
Re: [Issue 5093] improve error for importing std.c.windows.windows
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 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 5219] New: @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 Summary: @noheap annotation Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2010-11-15 13:44:26 PST --- In D often heap allocations are the main cause of low performance code, or they may cause less deterministic code (in video games, etc). A function annotation named "@noheap" may help (similar to @nothrow), it makes sure a function/method contains no heap allocations (new of arrays/objects/structs, array concat, array append, closures, associative array insertions, malloc/realloc/calloc, and so on, but not alloca()) and doesn't call other things that perform heap allocations. -- 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
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 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
[Issue 5218] New: Can't implicitly convert from "abc"w to wchar[3]
http://d.puremagic.com/issues/show_bug.cgi?id=5218 Summary: Can't implicitly convert from "abc"w to wchar[3] Product: D Version: D1 & D2 Platform: Other OS/Version: Windows Status: NEW Keywords: rejects-valid Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: clugd...@yahoo.com.au --- Comment #0 from Don 2010-11-15 13:09:39 PST --- ... though you can with char. This code also worked in D1. --- void bug5218c(char [3] s) {} void bug5218w(wchar [3] s) {} void bug5218d(dchar [3] s) {} void main() { bug5218c("abc"); bug5218w("abc"w); bug5218d("abc"d); } -- 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
d-bugm...@puremagic.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=5093 --- Comment #3 from simon 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.
[Issue 4837] ICE(constfold.c) CTFE with >>>=
http://d.puremagic.com/issues/show_bug.cgi?id=4837 --- Comment #2 from Don 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: ---
[Issue 4837] ICE(constfold.c) CTFE with >>>=
http://d.puremagic.com/issues/show_bug.cgi?id=4837 simon changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|nob...@puremagic.com|s.d.hamm...@googlemail.com --- Comment #1 from simon 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 5090] ICE(todt.c) struct literal initializing zero length array
http://d.puremagic.com/issues/show_bug.cgi?id=5090 --- Comment #3 from Iain Buclaw 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 5090] ICE(todt.c) struct literal initializing zero length array
http://d.puremagic.com/issues/show_bug.cgi?id=5090 simon changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|nob...@puremagic.com|s.d.hamm...@googlemail.com --- Comment #2 from simon 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 5093] improve error for importing std.c.windows.windows
http://d.puremagic.com/issues/show_bug.cgi?id=5093 --- Comment #3 from simon 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 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #86 from Leandro Lucarella 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 3463] Integrate Precise Heap Scanning Into the GC
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 5208] Inconsistency between src and import druntime files.
http://d.puremagic.com/issues/show_bug.cgi?id=5208 Steven Schveighoffer changed: What|Removed |Added Status|NEW |RESOLVED CC||schvei...@yahoo.com Resolution||DUPLICATE --- Comment #2 from Steven Schveighoffer 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 5205] D runtime duplication in zip
http://d.puremagic.com/issues/show_bug.cgi?id=5205 Steven Schveighoffer changed: What|Removed |Added CC||ibuc...@ubuntu.com --- Comment #4 from Steven Schveighoffer 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 3749] cannot evaluate yl2x (log) and exp functions at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=3749 --- Comment #8 from simon 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 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #84 from Leandro Lucarella 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 3463] Integrate Precise Heap Scanning Into the GC
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 4484] Warning for unreachable code in scope statements is too confusing
http://d.puremagic.com/issues/show_bug.cgi?id=4484 Jonathan M Davis changed: What|Removed |Added Keywords||rejects-valid Severity|enhancement |normal --- Comment #1 from Jonathan M Davis 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 4615] dmdscript no longer compiles
http://d.puremagic.com/issues/show_bug.cgi?id=4615 Don changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||WORKSFORME --- Comment #1 from Don 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 3293] ICE(expression.c) recursive alias template parameters
http://d.puremagic.com/issues/show_bug.cgi?id=3293 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Don 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 3493] Segfault(cast.c) Forward reference with type inference, D1 only.
http://d.puremagic.com/issues/show_bug.cgi?id=3493 Don changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #5 from Don 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 2080] ICE(mangle.c) alias corrupts type inference of static variables
http://d.puremagic.com/issues/show_bug.cgi?id=2080 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Don 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 4781] Segfault(mtype.c) with forward referenced typeof and .init
http://d.puremagic.com/issues/show_bug.cgi?id=4781 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Don 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: ---