[Issue 6189] [64bit] optimizer: register content destroyed in function prolog
http://d.puremagic.com/issues/show_bug.cgi?id=6189 --- Comment #14 from github-bugzi...@puremagic.com 2012-05-22 23:42:39 PDT --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/69634f17f19663c100fd47392b25160c404843eb fix Issue 6189 - [64bit] optimizer: register content destroyed in function prolog -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6189] [64bit] optimizer: register content destroyed in function prolog
http://d.puremagic.com/issues/show_bug.cgi?id=6189 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #16 from Walter Bright bugzi...@digitalmars.com 2012-05-22 23:44:34 PDT --- I added an assert to detect if other cases of this show up. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6189] [64bit] optimizer: register content destroyed in function prolog
http://d.puremagic.com/issues/show_bug.cgi?id=6189 --- Comment #15 from github-bugzi...@puremagic.com 2012-05-22 23:42:50 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/41b1412aca8e8d9370d4479a1f52388c69685592 fix Issue 6189 - [64bit] optimizer: register content destroyed in function prolog -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4310] std.stdarg 64-Bit problems?
http://d.puremagic.com/issues/show_bug.cgi?id=4310 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Component|Phobos |websites --- Comment #1 from Don clugd...@yahoo.com.au 2012-05-22 23:59:15 PDT --- The use of size_t is OK, but the example code should be using std.stdarg, va_arg!(arg), etc. Changing to a website bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6576] std.string.format for struct crash on Linux 64bit
http://d.puremagic.com/issues/show_bug.cgi?id=6576 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Component|DMD |Phobos --- Comment #4 from Don clugd...@yahoo.com.au 2012-05-23 00:14:38 PDT --- I thought this was a duplicate of bug 6758, but it isn't. Although 6758 is fixed, and even the wrong-code bug 6189, this still remains. std.format.doFormat around line 4845 has enough version(X86_64) stuff that it looks like a Phobos bug. I find it a bit scary that it bypasses core.stdarg, and there are not enough comments in that code for me to trust it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5570] 64 bit C ABI not followed for passing structs and complex numbers as function parameters
http://d.puremagic.com/issues/show_bug.cgi?id=5570 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #18 from Don clugd...@yahoo.com.au 2012-05-23 01:18:18 PDT --- Another commit towards this issue: https://github.com/D-Programming-Language/dmd/commit/29eb972a2f329276a72a19e722671ff26bfe8534 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8133] New: regression(2.059): D shared lib on OSX fails in 2.059, worked in 2.058
http://d.puremagic.com/issues/show_bug.cgi?id=8133
Summary: regression(2.059): D shared lib on OSX fails in 2.059,
worked in 2.058
Product: D
Version: D2
Platform: All
OS/Version: Mac OS X
Status: NEW
Severity: regression
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: thelastmamm...@gmail.com
--- Comment #0 from thelastmamm...@gmail.com 2012-05-23 01:26:10 PDT ---
The simplest possible shared lib in D (see details below) worked in 2.058 but
fails in 2.059.
I submitted a related (lib instead of dylib) bug report (Issue 7995) which was
fixed by pull request #205 from jacob-carlborg/7995. However the code fragment
below (shared lib) still fails even after applying that fix (which was pushed
to master).
cat main.c:
extern int fun();
int main(){return fun();}
cat fun.d:
module fun;
static import core.runtime;
extern (C) export int fun() {
core.runtime.Runtime.initialize();
return 0;
}
dmd -shared fun.d -oflibfun.dylib
gcc -o main main.c -L. -lfun
gdb ./main
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
0x0001ce6c in __tls_get_addr ()
(gdb) where
#0 0x0001ce6c in __tls_get_addr ()
#1 0x0001bddb in thread_attachThis ()
#2 0x0001bc6c in thread_init ()
#3 0x0001d36a in gc_init ()
#4 0x000100014035 in rt_init ()
#5 0x0001a5f7 in
D4core7runtime7Runtime10initializeFDFC6object9ThrowableZvZb ()
#6 0x00013ead in fun ()
#7 0x00010f1f in main ()
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8133] regression(2.059): D shared lib on OSX fails in 2.059, worked in 2.058
http://d.puremagic.com/issues/show_bug.cgi?id=8133 --- Comment #2 from Jacob Carlborg d...@me.com 2012-05-23 02:28:23 PDT --- (In reply to comment #1) The 2.059 release has the same behavior as the latest commit with the pull request applied so I don't understand what Walter is talking about. That should have been: Walter's example from the comment to the pull request has the same behavior using the 2.059 release as the latest commit with the pull request applied. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8133] regression(2.059): D shared lib on OSX fails in 2.059, worked in 2.058
http://d.puremagic.com/issues/show_bug.cgi?id=8133 Jacob Carlborg d...@me.com changed: What|Removed |Added CC||d...@me.com --- Comment #1 from Jacob Carlborg d...@me.com 2012-05-23 02:26:07 PDT --- That was revert, for some reason. I never got a good explanation from Walter: https://github.com/D-Programming-Language/druntime/pull/205#issuecomment-5675090 The 2.059 release has the same behavior as the latest commit with the pull request applied so I don't understand what Walter is talking about. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8040] writeln(null) too
http://d.puremagic.com/issues/show_bug.cgi?id=8040 --- Comment #2 from bearophile_h...@eml.cc 2012-05-23 03:01:57 PDT --- (In reply to comment #1) https://github.com/D-Programming-Language/phobos/pull/599 With my pull, original code output is: null null null Thank you Kenji Hara, this is an improvement. But isn't it better to add types (as in cast(Foo) or cast(Bar*)) to better tell apart the three kinds of null in that example? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8040] writeln(null) too
http://d.puremagic.com/issues/show_bug.cgi?id=8040 --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-05-23 03:26:04 PDT --- (In reply to comment #2) (In reply to comment #1) But isn't it better to add types (as in cast(Foo) or cast(Bar*)) to better tell apart the three kinds of null in that example? No, it isn't. It is consistent with other literal formatting. writeln(1); // prints 1, not cast(int)1 writeln(1L); // prints 1, not cast(long)1 writeln(1f); // prints 1, not cast(float)1 And, formatting as like cast syntax will make unfomatting complicate. It is less benefit. Furthermore, std.format module does not print value type in general. (Deprecated typedef value was formatted like cast syntax, but I think it is special case) Therefore, I think your proposal has many faults than benefits. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8040] writeln(null) too
http://d.puremagic.com/issues/show_bug.cgi?id=8040 --- Comment #4 from bearophile_h...@eml.cc 2012-05-23 04:07:37 PDT --- (In reply to comment #3) writeln(1); // prints 1, not cast(int)1 writeln(1L); // prints 1, not cast(long)1 writeln(1f); // prints 1, not cast(float)1 In my opinion writeln(1f) and writeln(1.0L) should print 1.0, as in Python: int(1) 1 float(1) 1.0 And, formatting as like cast syntax will make unfomatting complicate. It is less benefit. Furthermore, std.format module does not print value type in general. (Deprecated typedef value was formatted like cast syntax, but I think it is special case) Therefore, I think your proposal has many faults than benefits. OK. Thank you for the answers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8134] New: Arguments getting nonsensical values in out contract when method is final
http://d.puremagic.com/issues/show_bug.cgi?id=8134
Summary: Arguments getting nonsensical values in out contract
when method is final
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: a...@lycus.org
--- Comment #0 from Alex R�nne Petersen a...@lycus.org 2012-05-23 15:14:34
CEST ---
The following code is broken:
void main()
{
auto foo = new class
{
final Object doNothing(Object obj)
out (result) { assert (result is obj); }
body {
return obj;
}
};
foo.doNothing(null);
}
The 'obj' parameter is set to some nonsensical value when doNothing() is marked
final. Remove the final and it works as expected.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7796] std.typecons.Unique is using writeln without importing std.stdio
http://d.puremagic.com/issues/show_bug.cgi?id=7796 --- Comment #1 from github-bugzi...@puremagic.com 2012-05-23 09:24:30 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/4ee4efe2b03d4d3221a96e06c6b10fd14350390e fix Issue 7796 - std.typecons.Unique is using writeln without importing std.stdio https://github.com/D-Programming-Language/phobos/commit/4a88cd82bf8abba0c799fe01537187a105a08299 Merge pull request #601 from 9rnsr/fix7796 Issue 7796 - std.typecons.Unique is using writeln without importing std.stdio -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4356] Copy constructor not called under extremely mysterious circumstances
http://d.puremagic.com/issues/show_bug.cgi?id=4356 --- Comment #3 from github-bugzi...@puremagic.com 2012-05-23 11:16:51 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/ca86dad193372aee89de3712dfab0589502f3564 Bug 4356 is fixed, use ordinary assertion. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7796] std.typecons.Unique is using writeln without importing std.stdio
http://d.puremagic.com/issues/show_bug.cgi?id=7796 --- Comment #2 from github-bugzi...@puremagic.com 2012-05-23 11:17:01 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/61f991ba515c5cb48b636a8c803ebbb5804e8508 Issue 7796 - std.typecons.Unique is using writeln without importing std.stdio. With Unique being a template, commit 4ee4efe (pull request #601) caused the messages to be printed for unittest builds of client code as well. https://github.com/D-Programming-Language/phobos/commit/a98fb93de808c99e0eba038d828b5cce2ee70ba5 Merge pull request #602 from klickverbot/trace-unique Issue 7796 - std.typecons.Unique is using writeln without importing std.stdio. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8135] New: throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135
Summary: throwing Error runs finally handler
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@dawgfoto.de
--- Comment #0 from d...@dawgfoto.de 2012-05-23 12:34:18 PDT ---
cat bug.d CODE
extern(C) int printf(const char*, ...);
void foo()
{
throw new Error(msg);
}
void main()
{
try
foo();
finally
printf(finally\n);
}
CODE
dmd -run bug
prints:
finally
object.Error: msg
expected:
object.Error: msg
The expected behavior was discussed in bug 7018 and on the mailing list.
Throwing Errors (http://forum.dlang.org/thread/1566418.J7qGkEti3s@lyonel)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8136] New: Stack unwinding example uses OutOfMemoryError
http://d.puremagic.com/issues/show_bug.cgi?id=8136 Summary: Stack unwinding example uses OutOfMemoryError Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: d...@dawgfoto.de --- Comment #0 from d...@dawgfoto.de 2012-05-23 12:39:30 PDT --- If code detects an error like out of memory, then an Error is thrown with a message saying Out of memory. The function call stack is unwound, looking for a handler for the Error. Finally blocks are executed as the stack is unwound. If an error handler is found, execution resumes there. If not, the default Error handler is run, which displays the message and terminates the program. This paragraph from http://dlang.org/errors.html exemplifies stack unwinding and cleanup. It should be changed to use an Exception. http://d.puremagic.com/issues/show_bug.cgi?id=8135 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8136] Stack unwinding example uses OutOfMemoryError
http://d.puremagic.com/issues/show_bug.cgi?id=8136 --- Comment #1 from d...@dawgfoto.de 2012-05-23 12:46:57 PDT --- The page (http://dlang.org/errors.html) should explain the difference between both kinds of Throwables, i.e. recoverable Exceptions and unrecoverable Errors. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8133] regression(2.059): D shared lib on OSX fails in 2.059, worked in 2.058
http://d.puremagic.com/issues/show_bug.cgi?id=8133 --- Comment #3 from thelastmamm...@gmail.com 2012-05-23 13:53:03 PDT --- (In reply to comment #2) (In reply to comment #1) The 2.059 release has the same behavior as the latest commit with the pull request applied so I don't understand what Walter is talking about. That should have been: Walter's example from the comment to the pull request has the same behavior using the 2.059 release as the latest commit with the pull request applied. I see. Indeed the fix you had supplied did fix both Issue 7995 and this current Issue 8133 (I had pulled in the meantime the master which reverted to before your fix). It would be really great if Walter could accept your pull request once again as it is a real blocker not to be able to build shared libs. I also don't really understand his concern in his comment. Perhaps you could bug him again? A unittest with such test cases would prevent further regressions. Also, I really think it should be made clear on the dlang website in release notes what is currently supported in each version. For example, diverse forums complain that support for shared libs on OSX is not working yet with the D runtime, but 2.058 or your fix seem to support those. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7995] regression(2.059): D runtime initialization from C fails on OSX in 2.059, worked in 2.058
http://d.puremagic.com/issues/show_bug.cgi?id=7995 --- Comment #5 from thelastmamm...@gmail.com 2012-05-23 13:58:33 PDT --- (In reply to comment #4) (In reply to comment #3) Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/714e86fb88459807f35fe7270da592ee06e40e31 Fix issue 7995: D runtime initialization from C fails on OSX in 2.059, worked in 2.058. I also refactored the startup code to remove duplicated code. This will hopefully reduce this kind of bugs in the future. https://github.com/D-Programming-Language/druntime/commit/6467f87e1a6b4696b9929c459b38477df1cf0522 Merge pull request #205 from jacob-carlborg/7995 Fix issue 7995: D runtime initialization from C fails on OSX in 2.059, w... Great, thanks, that appears to solve THAT bug, however I filed a new regression bug for a related problem (with dylib instead of lib): see Issue 8133. Actually the pull request seems to fix Issue 8133 (but master had reverted it in the meantime). It would be nice to have this pull request back in master ... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8135] throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jmdavisp...@gmx.com Resolution||INVALID --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-05-23 14:06:36 PDT --- This is not a bug. Per the lanugage, there is no guarantee that finally blocks, scope statements, or destructors will be run when an Error is thrown, but neither is there any guarantee that they _won't_ be. So, while relying on them being executed when an Error is thrown is a bad idea, relying on them _not_ being executed when an Error is thrown is also a bad idea. The current implementation _does_ always execute finally blocks, scope statements, and destructors with Errors just like would occur with Exceptions, and there is quite a lot of debate over whether the language should be changed to reflect that. Walter is against it, but he's also one of the few who even realized that the language didn't guarantee that they would be executed for Errors. Other people who have been working on the exception handling in the compiler and druntime _did_ think that it was guaranteed, and they wrote that code with that in mind. In addition, I believe that the spec itself is actually silent on the matter. So, the short answer is that you should never rely on scope statements, finally blocks, or destructors being run or not run when an Error is thrown. A more thorough discussion of the issues is in this thread on dmd-internals: http://forum.dlang.org/post/1566418.J7qGkEti3s@lyonel -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8135] throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135 --- Comment #2 from d...@dawgfoto.de 2012-05-23 19:40:45 PDT --- The current implementation _does_ always execute finally blocks, scope statements, and destructors with Errors just like would occur with Exceptions No they are not when you throw from a nothrow function. This is even worse when nothrow is inferred, because the actual behavior becomes instable. So, the short answer is that you should never rely on scope statements, finally blocks, or destructors being run or not run when an Error is thrown. This is not an acceptable solution. The problem needs a clean decision and an according implementation or it will continue to create confusion. https://github.com/D-Programming-Language/druntime/pull/225#issuecomment-5857155 I'm wondering how the decision to use EH for fatal errors was made. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8135] throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135 --- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2012-05-23 19:53:36 PDT --- Well, unstable behavior from an Error is pretty much a given if your program doesn't die from it, unless it were treated completely like an Exception, in which case you couldn't throw an Error (including OutOfMemoryError) from a nothrow function, which would be unacceptable. Your program is pretty much instantly in an unstable state as soon as an Error is thrown. It's just a question of _how_ unstable, and the given implementation attempts far more cleanup than is technically required according to Walter, which is a double-edged sword, since that tends to make the code more stable when an Error is thrown, but if your program is in a bad state thanks to whatever caused the Error to be thrown, trying to do that cleanup could just make things worse. Regardless, I completely agree that the situation needs to be clarified. We've got the implementation going one way and Walter arguing another. And it would certainly be better if it were guaranteed that finally and friends were never executed when an Error is thrown than having them executed right now but possibly not later when the implementation is tweaked. So, in principle, I agree with the bug report, but as it stands, the current implementation is within the required behavior. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8135] throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added CC||a...@lycus.org --- Comment #4 from Alex R�nne Petersen a...@lycus.org 2012-05-24 04:59:41 CEST --- FWIW, I'm all for making Errors actually fatal and terminating the runtime immediately, but then OutOfMemory*Error* HAS GOT TO GO. I use D as a systems language, not as an applications language, and I *have* to be able to catch an out of memory condition. I don't know why this was made an Error in the first place, and in a systems language of all things. Yes, most developers may get it wrong, but what about the few of us that *don't*? Just my 2 cents/frustration as a developer writing a virtual machine in D... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8137] New: Handling of Errors should be defined
http://d.puremagic.com/issues/show_bug.cgi?id=8137 Summary: Handling of Errors should be defined Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-05-23 20:00:21 PDT --- As discussed in this thread ( http://forum.dlang.org/post/1566418.J7qGkEti3s@lyonel ), according to Walter, it is _not_ guaranteed that finally blocks, scope statements, and destructors will be run when an Error is thrown. However, the current implementation guarantees it in almost all circumstances (nothrow functions are one exception, I believe). As it stands, code is being written with the assumption that Errors _do_ trigger those constructs (especially with regards to AssertError). So, if the current behavior ever changes, it could break a lot of code. There is quite a lot of dispute in that thread about what the behavior should be (guarantee cleanup or don't guarantee cleanup). We need a decision on this and to make the implementation match that and be _guaranteed_ to match it, with the spec reflecting it. Otherwise, we have undefined behavior (which D typically tries to avoid) which quite a few programs are currently relying on and which may change in the future. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8135] throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135 --- Comment #5 from Jonathan M Davis jmdavisp...@gmx.com 2012-05-23 20:04:56 PDT --- Walter is of the firm belief that running out of memory is essentially unrecoverable, so I don't see OutOfMemoryError ever being anything other than an Error. If you really can't deal with that, you're probably going to have to use something other than the GC for memory management (or wrap all GC allocations in functions that can catch and deal with OutOfMemoryError immediately after its thrown). Even if the cleanup doesn't occur for Errors, it's quite possible to catch them and handle them, and if you catch them very close to the throw point, you can do so relatively safely. It's catching them far from the throw point that isn't going to work. http://d.puremagic.com/issues/show_bug.cgi?id=8137 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8135] throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135 --- Comment #6 from Alex R�nne Petersen a...@lycus.org 2012-05-24 05:10:03 CEST --- From TDPL �9.4: If you catch a Throwable, you may only perform a number of simple operations; most of the time, you probably want to print a message to the standard error or a log file, attempt to save whatever you can save to a separate file, stiffen that upper lip, and exit with as much dignity as possible. This doesn't seem terribly encouraging... Essentially, I need to catch OOME and continue full-blown program execution, which is very worrying. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8135] throwing Error runs finally handler
http://d.puremagic.com/issues/show_bug.cgi?id=8135 --- Comment #7 from Jonathan M Davis jmdavisp...@gmx.com 2012-05-23 20:19:00 PDT --- You should be able to do so under very limited circumstances, but it was definitely a design decision of D that running out of memory would be considered to be unrecoverable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8138] New: Attribute inference fails with Voldemort type
http://d.puremagic.com/issues/show_bug.cgi?id=8138
Summary: Attribute inference fails with Voldemort type
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-05-23 21:47:20
PDT ---
This stripped down code from one of my programs
import std.algorithm;
import std.range;
import std.traits;
void main()
{
ubyte[] buffer = [1, 2, 9, 7, 6];
auto filtered = filter!true(buffer);
auto br2 = bitReader(filtered);
}
final class BitReader(R)
if(isInputRange!R is(ElementType!R : const ubyte))
{
this(R)(R bytes)
{
_bytes = bytes;
}
@property bool empty() const
{
return _bytes.empty;
}
R _bytes;
}
BitReader!R bitReader(R)(R r)
if(isInputRange!R is(ElementType!R : const ubyte))
{
return new BitReader!R(r);
}
results in this compilation error:
q.d(24): Error: function
std.algorithm.filter!(true).filter!(ubyte[]).filter.Result.empty () is not
callable using argument types (
If empty is changed to mutable, the code compiles just fine, but if it's either
const or inout, it fails. Given that the empty that filter's Result's empty is
calling is std.array.empty (whose parameter is in), filter's Result's empty
should be inferred as const, but it appears that it's not, since my class'
empty can't be const due to the call to filter's Result's empty.
My _guess_ would be that the problem stems from the fact that Result isn't
templated (rather filter is templated, and Result is generated as part of that
template), but I don't know. Regarldess, this is a major problem for constness
and Voldemort types.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
