[Issue 6620] argument evaluation order inversed for extern(C)
https://issues.dlang.org/show_bug.cgi?id=6620 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, wrong-code Hardware|Other |All OS|FreeBSD |All --- Comment #3 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4035 --
[Issue 13560] New: Several functions in std.uni can violate memory safety
https://issues.dlang.org/show_bug.cgi?id=13560 Issue ID: 13560 Summary: Several functions in std.uni can violate memory safety Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: tta...@gmail.com In std/uni.d, there is a line with `@trusted:` in the line 6380. But decodeGrapheme, byGrapheme and other functions should not be trusted because their memory safety depends on the static argument for them. Furthermore, there are several functions and methods individually marked as trusted/safe after the line 6380. Other functions after line 6380 seem to be accidentally marked as trusted. We should remove such `@trusted:` and make each function safe or trusted after carefully checking its memory safety. --
[Issue 11806] Freeze in GC.collect() in in-contracts when multithreading is used
https://issues.dlang.org/show_bug.cgi?id=11806 badlink andrea.9...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||andrea.9...@gmail.com Resolution|FIXED |--- --- Comment #3 from badlink andrea.9...@gmail.com --- The deadlock is still present in DMD 2.066 and 2.067.0-b1 (on linux x86_64) Stacktrace of the sample program http://pastebin.com/iXWWrcBR --
[Issue 4890] GC.collect() deadlocks multithreaded program.
https://issues.dlang.org/show_bug.cgi?id=4890 --- Comment #29 from badlink andrea.9...@gmail.com --- Also present in DMD 2.067.0-b1. Stacktrace of the sample program in comment 10: http://pastebin.com/4mudSeEX --
[Issue 11216] Make synchronized statement `nothrow`
https://issues.dlang.org/show_bug.cgi?id=11216 Martin Nowak c...@dawg.eu changed: What|Removed |Added Priority|P2 |P5 CC||c...@dawg.eu --- Comment #2 from Martin Nowak c...@dawg.eu --- I'm in favor of doing this. Is there a migration path for requiring nothrow on the Monitor Interface without breaking code? --
[Issue 13561] New: enumProcessThreads should be nothrow
https://issues.dlang.org/show_bug.cgi?id=13561 Issue ID: 13561 Summary: enumProcessThreads should be nothrow Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: c...@dawg.eu Depends on: 11216 The function enumProcessThreads [1] in core.sys.windows.threadaux should be nothrow, but it depends on some core.thread functions. Fixing those requires a workaround/fix for bug 11216. Once enumProcessThreads is nothrow we can remove this workaround [2]. [1]: https://github.com/D-Programming-Language/druntime/blob/6e929bc0b8dc29cff18dcf1c5f5866de98d069b3/src/core/sys/windows/threadaux.d#L212 [2]: https://github.com/D-Programming-Language/druntime/pull/974#issuecomment-57394531 --
[Issue 11216] Make synchronized statement `nothrow`
https://issues.dlang.org/show_bug.cgi?id=11216 Martin Nowak c...@dawg.eu changed: What|Removed |Added Blocks||13561 --
[Issue 11806] Freeze in GC.collect() in in-contracts when multithreading is used
https://issues.dlang.org/show_bug.cgi?id=11806 badlink andrea.9...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from badlink andrea.9...@gmail.com --- Both issues show a deadlock after a call to gc.gc.Gcx.fullcollect(). In this particular case, the GC collection is triggered by continuously allocating exceptions in the base contract because of assert(false). *** This issue has been marked as a duplicate of issue 4890 *** --
[Issue 4890] GC.collect() deadlocks multithreaded program.
https://issues.dlang.org/show_bug.cgi?id=4890 badlink andrea.9...@gmail.com changed: What|Removed |Added CC||christ...@nerdtools.de --- Comment #30 from badlink andrea.9...@gmail.com --- *** Issue 11806 has been marked as a duplicate of this issue. *** --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #23 from Martin Nowak c...@dawg.eu --- I don't really agree with this patch. HashTables are unordered and optimized for random indexing by a key. If you run a tight loop and constantly query front (abusing byKey) then of course that's expensive O(N^2/2). It's like taking a singly linked list and removing the last element until it's empty. Instead we should offer a nice and generic remove function that takes a predicate and allows to batch remove entries. --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 --- Comment #24 from Martin Nowak c...@dawg.eu --- In other words, this optimizes the following code foreach (_; 0 .. 1_000_000) aa.byKey(); but pessimizes the following aa.remove(key); It does NOT improve iterating byKey. So unless there is a valid use case to call aa.byKey.front in a loop this would only improve a pointless microbenchmark. Batch deletion is much better done with a dedicated remove function. aa.remove((k, v) = pred(k)); Any volunteers for implementing the latter? --
[Issue 13562] New: [Enh] add permute[=seed] command line argument to dmd
https://issues.dlang.org/show_bug.cgi?id=13562 Issue ID: 13562 Summary: [Enh] add permute[=seed] command line argument to dmd Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com Return-Oriented-Programming (ROP) is a common attack method that malware uses to exploit buffer overflows: http://en.wikipedia.org/wiki/Return-oriented_programming It relies on code having predictable contents and being in predictable locations. The compiler often makes potayto-potahto decisions when generating code. By optionally providing a random value to the compiler, it can use that to toss a coin for the decision, making the generated code slightly different - different enough to defeat many ROP attacks. Perturbations can be: changing the stack layout of locals changing the order of register selection changing the scheduling order of instructions weights given to loop variables instruction selection etc. Syntax: -perturb=seed// use seed to guide the compiler's coin toss -perturb // have the compiler generate its own seed, likely by // using the clock. -v will cause this value to be printed default // use a seed value of 0, causing the same behavior the // compiler has now Using this can also shake out compiler bugs by fuzz testing of different paths through the compiler. It can help isolate stack corruption code bugs by helping find a more reproducible test case. This switch can be particularly useful for those who are willing to build their apps from source, so that their executable will be different from anybody else's built from the identical source. It shouldn't be hard to implement. --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 --- Comment #25 from Ketmar Dark ket...@ketmar.no-ip.org --- and we can make it alot less expensive without losing speed. and all this with only 4/8 bytes of overhead for single AA (not for single AA entry, but for the whole AA). the only questionable thing with this patch is that it assumes that AA is mutable. but we can't have AA literals anyway, AFAIK. and no, it's not really pessimizes remove() if noone used .byKey/.byValue on AA, and even if that properties was used, next rehashing will turn off caching again. so i daresay that remove() slowdown is not noticable at all. --
[Issue 649] concatenation hangs in threaded program
https://issues.dlang.org/show_bug.cgi?id=649
badlink andrea.9...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||andrea.9...@gmail.com
Resolution|--- |FIXED
--- Comment #6 from badlink andrea.9...@gmail.com ---
The program exits normally on Arch Linux (DMD 2.067.0-b1)
I have updated the test case:
import core.thread;
import std.string;
extern(C) uint sleep(uint secs);
class Test {
Thread thr;
void printStats() {
sleep(1);
char[] r;
r ~= a;
}
this() {
thr = new Thread(printStats);
thr.start();
}
~this() {
thr.join();
}
}
void main() {
Test t = new Test();
destroy(t);
}
--
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 --- Comment #26 from bearophile_h...@eml.cc --- (In reply to Martin Nowak from comment #24) So unless there is a valid use case to call aa.byKey.front in a loop this would only improve a pointless microbenchmark. See here, it's not just a pointless microbenchmark: http://forum.dlang.org/thread/efmjlfpehqqfszcrx...@forum.dlang.org As shown by others, there are ways to rewrite that code to avoid most of the very slow part, but popping the first item from an an associative array is a sufficiently common operation (I have written and seen plenty of Python code that does it). --
[Issue 13458] std.utf.decode not @nogc
https://issues.dlang.org/show_bug.cgi?id=13458 --- Comment #1 from Robert Schadek rburn...@gmail.com --- http://forum.dlang.org/post/nmekkwvomoztshgla...@forum.dlang.org --
[Issue 13558] GC.free does not work for array pointers of larger size
https://issues.dlang.org/show_bug.cgi?id=13558 Leandro Lucarella leandro.lucare...@sociomantic.com changed: What|Removed |Added CC||leandro.lucarella@sociomant ||ic.com --
[Issue 13563] New: ICE with opIndexAssign op-overloading and ModuleScopeOperator
https://issues.dlang.org/show_bug.cgi?id=13563
Issue ID: 13563
Summary: ICE with opIndexAssign op-overloading and
ModuleScopeOperator
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: ice
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
Separating issue from https://issues.dlang.org/show_bug.cgi?id=13356#c1
void writeConfig()
{
JSONValue v;
v[name] = .z();
}
struct JSONValue
{
import std.variant;
alias Payload = Algebraic!(typeof(null));
Payload payload;
alias payload this;
}
Simplified test case:
struct Payload
{
void opIndex(K)(K i) {}
void opIndexAssign(T, N)(T value, N i) {}
}
struct Value
{
Payload payload;
alias payload this;
}
void main()
{
Value v;
v[name] = .z();
}
--
[Issue 13563] ICE with opIndexAssign op-overloading and ModuleScopeOperator
https://issues.dlang.org/show_bug.cgi?id=13563 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4037 --
[Issue 13356] [ICE] (dmd 2.066: statement.c:754) with recursive Algebraic
https://issues.dlang.org/show_bug.cgi?id=13356 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||ice, pull Hardware|x86_64 |All OS|Linux |All Severity|normal |major --- Comment #2 from Kenji Hara k.hara...@gmail.com --- (In reply to Philippe Sigaud from comment #0) This creates an [ICE] (2.066): [snip] Compiler fix: https://github.com/D-Programming-Language/dmd/pull/4036 (In reply to John Colvin from comment #1) Another test case: [snip] The root problem of the second case was bit different from the first case, so I separated it into issue 13563. --
[Issue 6620] argument evaluation order inversed for extern(C)
https://issues.dlang.org/show_bug.cgi?id=6620 --- Comment #4 from Kenji Hara k.hara...@gmail.com --- (In reply to Kenji Hara from comment #3) https://github.com/D-Programming-Language/dmd/pull/4035 A small supplemental documentation fix: https://github.com/D-Programming-Language/dlang.org/pull/669 --
[Issue 13563] ICE with opIndexAssign op-overloading and ModuleScopeOperator
https://issues.dlang.org/show_bug.cgi?id=13563 John Colvin john.loughran.col...@gmail.com changed: What|Removed |Added CC||john.loughran.colvin@gmail. ||com --
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly.
https://issues.dlang.org/show_bug.cgi?id=2043
Gabor Mezo gabor.m...@outlook.com changed:
What|Removed |Added
CC||gabor.m...@outlook.com
--- Comment #10 from Gabor Mezo gabor.m...@outlook.com ---
Actually, I find this style of workaround mutch more readable than we seen
before:
foreach (idx; 1 .. data.length)
{
(idx)
{
// Do stuff
}(idx);
}
It not looks too ugly if you have some JS background. :)
Please fix this bug ASAP. I really like this language but this POS always makes
me sad if I take a look at my code.
--
[Issue 13525] Redundant SpecialKeyword grammar listd in DefaultInitializerExpression
https://issues.dlang.org/show_bug.cgi?id=13525 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13525] Redundant SpecialKeyword grammar listd in DefaultInitializerExpression
https://issues.dlang.org/show_bug.cgi?id=13525 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/0b4db24b5b07c3051bcf6c06860774d48be77f11 fix Issue 13525 - Redundant SpecialKeyword grammar listd in DefaultInitializerExpression Remove DefaultInitializerExpression and replace with AssignExpression https://github.com/D-Programming-Language/dlang.org/commit/01a407c157eefe5e1bcdfb37f2514f79409d3958 Merge pull request #661 from 9rnsr/fix13525 Issue 13525 - Redundant SpecialKeyword grammar listd in DefaultInitializerExpression --
[Issue 10233] [Tracker] Grammar issues
https://issues.dlang.org/show_bug.cgi?id=10233 Issue 10233 depends on issue 13525, which changed state. Issue 13525 Summary: Redundant SpecialKeyword grammar listd in DefaultInitializerExpression https://issues.dlang.org/show_bug.cgi?id=13525 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||jmdavisp...@gmx.com, ||schvei...@yahoo.com --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com --- CCing Jonathan. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 Marco Leise marco.le...@gmx.de changed: What|Removed |Added CC||marco.le...@gmx.de --- Comment #4 from Marco Leise marco.le...@gmx.de --- Yes, he is the master of time. --
[Issue 12985] Better error message for not supported array operation
https://issues.dlang.org/show_bug.cgi?id=12985 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Hardware|x86 |All OS|Windows |All --- Comment #4 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4039 --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 --- Comment #27 from hst...@quickfur.ath.cx --- @bearophile: perhaps that's an indication that what you want is actually an *ordered* map, not a hash map? --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 --- Comment #28 from Steven Schveighoffer schvei...@yahoo.com --- New simpler pull which shouldn't affect performance of aa.remove https://github.com/D-Programming-Language/druntime/pull/979 --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 --- Comment #29 from bearophile_h...@eml.cc --- (In reply to hsteoh from comment #27) @bearophile: perhaps that's an indication that what you want is actually an *ordered* map, not a hash map? Nope. If you take a look at the link, that code doesn't need an ordered container. The pop operation just needs to give one arbitrary item. --
[Issue 13564] New: nested struct destructor trying to access members of a global class fail to compile
https://issues.dlang.org/show_bug.cgi?id=13564
Issue ID: 13564
Summary: nested struct destructor trying to access members of a
global class fail to compile
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: ac...@free.fr
The following code used to compile, but doesn't anymore:
class Element(T)
{
int pos;
}
class Container(T)
{
struct Structure
{
~this()
{
Container!int c;
c.element.pos = 0;
}
}
Element!T element;
}
void f()
{
new Container!int ();
}
ace@ANTEC /tmp % dmd yo.d
yo.d(13): Error: no property 'pos' for type 'Element!int'
yo.d(22): Error: template instance yo.Container!int error instantiating
It doesn't occur if Structure is moved out of Container.
It doesn't occur if the destructor is replaced by a regular function.
Is this normal?
--
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 --- Comment #30 from Steven Schveighoffer schvei...@yahoo.com --- bearophile or ketmar, can you test the new PR? The timings I get on my system are not very different from the original. --
[Issue 13565] New: add AA batch remove using a predicate function
https://issues.dlang.org/show_bug.cgi?id=13565
Issue ID: 13565
Summary: add AA batch remove using a predicate function
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P2
Component: druntime
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
To remove multiple AA entries at once we should support calling aa.remove with
a predicate function, taking key and value.
Old code:
Louter: while (true)
{
Key key;
foreach (k, v; aa) {
if (!pred(k, v)) continue;
aa.remove(k);
continue Louter;
}
break;
}
New code:
aa.remove((k, v) = pred(k, v));
--
[Issue 13554] adding ExitError which can be thrown to 'exit with exit code'
https://issues.dlang.org/show_bug.cgi?id=13554 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- This seems to be a duplicate of issue #3462. --
[Issue 13554] adding ExitError which can be thrown to 'exit with exit code'
https://issues.dlang.org/show_bug.cgi?id=13554 --- Comment #2 from hst...@quickfur.ath.cx --- Maybe you could attach your patch to the other issue and close this one as a duplicate? --
[Issue 13555] Categorize functions in std.math
https://issues.dlang.org/show_bug.cgi?id=13555 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 --- Comment #31 from Martin Nowak c...@dawg.eu --- (In reply to bearophile_hugs from comment #29) Nope. If you take a look at the link, that code doesn't need an ordered container. The pop operation just needs to give one arbitrary item. Take an array or a stack for that. --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 --- Comment #32 from bearophile_h...@eml.cc --- (In reply to Martin Nowak from comment #31) (In reply to bearophile_hugs from comment #29) Nope. If you take a look at the link, that code doesn't need an ordered container. The pop operation just needs to give one arbitrary item. Take an array or a stack for that. Nope, the associative array nature is needed for other reasons by the code. And keeping the same keys in two collections in parallel is a waste. --
[Issue 13566] New: std.algorithm.cmp treats string length as element
https://issues.dlang.org/show_bug.cgi?id=13566
Issue ID: 13566
Summary: std.algorithm.cmp treats string length as element
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: acehr...@yahoo.com
The following code cannot be compiled on a 64-bit environment:
import std.algorithm;
bool myPred(dchar a, dchar b)
{
return false;
}
void main()
{
cmp!myPred(, );
}
phobos/std/algorithm.d(7314): Error: myPred (dchar a, dchar b) is not callable
using argument types (ulong, ulong)
phobos/std/algorithm.d(7314): Error: myPred (dchar a, dchar b) is not callable
using argument types (ulong, ulong)
deneme.d(179975): Error: template instance std.algorithm.cmp!(myPred, string,
string) error instantiating
A quick investigation reveals that one of the overloads of threeWay() inside
std.algorithm.cmp takes two size_t parameters that are supposed to be string
lengths. Unfortunately, threeWay() then tries to pass those lengths to the
predicate:
// For speed only
static int threeWay(size_t a, size_t b)
{
static if (size_t.sizeof == int.sizeof isLessThan)
return a - b;
else
return binaryFun!pred(b, a) ? 1 : binaryFun!pred(a, b) ? -1 : 0; //
-- HERE
}
I've also noticed that unittests of cmp() don't consider special predicates at
all. ;)
Ali
--
[Issue 13566] std.algorithm.cmp treats string length as element
https://issues.dlang.org/show_bug.cgi?id=13566 Ali Cehreli acehr...@yahoo.com changed: What|Removed |Added Priority|P1 |P3 --
[Issue 13555] Categorize functions in std.math
https://issues.dlang.org/show_bug.cgi?id=13555 Mark Isaacson marki...@umich.edu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --
[Issue 13567] New: Attribute inference for private functions
https://issues.dlang.org/show_bug.cgi?id=13567 Issue ID: 13567 Summary: Attribute inference for private functions Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: gox...@gmail.com Previously attribute inference was considered for all auto functions, but there was no consensus reached. Using attribute inference for private functions avoids all previously raised concerns except slows down compilation. Walter: Please file as an enhancement request. The more attribute inference we can do, the better. --
[Issue 13567] Attribute inference for private functions
https://issues.dlang.org/show_bug.cgi?id=13567 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- I agree with this. Private functions don't suffer from the same objections raised against adding inference to auto functions, so perhaps this is the way to go to increase the scope of attribute inference in D. --
[Issue 13548] wrong FP comparison
https://issues.dlang.org/show_bug.cgi?id=13548 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 13537] Unions may break immutability
https://issues.dlang.org/show_bug.cgi?id=13537 --- Comment #1 from hst...@quickfur.ath.cx --- Basically, immutable cannot be allowed to overlap with anything mutable, otherwise there will be a way to break the immutability guarantee. --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 Ketmar Dark ket...@ketmar.no-ip.org changed: What|Removed |Added CC|ket...@ketmar.no-ip.org | --- Comment #33 from Ketmar Dark ket...@ketmar.no-ip.org --- (In reply to Steven Schveighoffer from comment #30) bearophile or ketmar, can you test the new PR? for what reason? see #2 and #3, i was tried the variant without caching in remove(). i'm telling again that remove() is NOT slowed down by any noticable time, and if you doing alot of removes which all happen to hit the first used bucket, and each such hit empties that bucket, and you used .byKey/.byValue before… this is very unusual scenario, and if you *know* that it goes like this, you can force rehashing. yet i'm not interested in defending the code: i integrated it in my local builds since i published the patch and it's ok for me. i don't really care if it will make to mainline in one form on another. --
[Issue 3462] Add a clean way to exit a process.
https://issues.dlang.org/show_bug.cgi?id=3462 --- Comment #13 from Ketmar Dark ket...@ketmar.no-ip.org --- *** Issue 13554 has been marked as a duplicate of this issue. *** --
[Issue 3462] Add a clean way to exit a process.
https://issues.dlang.org/show_bug.cgi?id=3462 Ketmar Dark ket...@ketmar.no-ip.org changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #12 from Ketmar Dark ket...@ketmar.no-ip.org --- Created attachment 1442 -- https://issues.dlang.org/attachment.cgi?id=1442action=edit another version, slightly less sophisticated adds ExitError which inherits Error (i intend it to be catchable with catch(Throwable)), respects `rt_trapExceptions` flag and adds nothing to std.process (throw your rocks at the door to exit! ;-). --
[Issue 13554] adding ExitError which can be thrown to 'exit with exit code'
https://issues.dlang.org/show_bug.cgi?id=13554 Ketmar Dark ket...@ketmar.no-ip.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ket...@ketmar.no-ip.org Resolution|--- |DUPLICATE --- Comment #3 from Ketmar Dark ket...@ketmar.no-ip.org --- (In reply to hsteoh from comment #2) Maybe you could attach your patch to the other issue and close this one as a duplicate? hm. i don't know how this will work with threads and never tested it (i'm not using multithreading alot, i prefer to fork() ;-). but yes, i can attach my patch there, no prob. *** This issue has been marked as a duplicate of issue 3462 *** --
[Issue 13468] std.algorithm.canFind(null) fails with class
https://issues.dlang.org/show_bug.cgi?id=13468 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- Found the cause of the bug. The problem is that when comparing two class references, the default predicate attempts to compare two class references with ==, which appears to dereference a NULL and cause a segfault. If a is b is used as predicate instead, there is no crash. Next is to find out why == doesn't handle null pointers correctly... --
[Issue 13468] std.algorithm.canFind(null) fails with class
https://issues.dlang.org/show_bug.cgi?id=13468 --- Comment #2 from hst...@quickfur.ath.cx --- Actually it's quite simple. The expression a == b, in the case of classes, is lowered into a.opEquals(b). Since a is null when find/canFind gets to a null element in the array, opEquals is invoked with a null this pointer, with disastrous consequences. --
[Issue 13556] inconsistent 'new' syntax for arrays
https://issues.dlang.org/show_bug.cgi?id=13556 --- Comment #3 from Kenji Hara k.hara...@gmail.com --- (In reply to bearophile_hugs from comment #1) I suspect that the array creation syntax is an unfixable mess. new int[256][256] can also be generate a pointer to fixed size array int[256][256]. I think all dynamic array allocation should be writtten as: int[][](1, 2) Current ambituity syntax new int[2][1] should be deprecated, removed, and then we can reuse it for static array allocation. --
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly.
https://issues.dlang.org/show_bug.cgi?id=2043 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||and...@erdani.com --- Comment #11 from Kenji Hara k.hara...@gmail.com --- *** Issue 8621 has been marked as a duplicate of this issue. *** --
[Issue 8621] Iteration variable in foreach not closed upon properly in delegate
https://issues.dlang.org/show_bug.cgi?id=8621 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Kenji Hara k.hara...@gmail.com --- *** This issue has been marked as a duplicate of issue 2043 *** --
