[Issue 17132] Using DLL makes an empty stacktrace on error
https://issues.dlang.org/show_bug.cgi?id=17132 j...@red.email.ne.jp changed: What|Removed |Added Keywords||dll --
[Issue 17132] Using DLL makes an empty stacktrace on error
https://issues.dlang.org/show_bug.cgi?id=17132 --- Comment #1 from j...@red.email.ne.jp --- The reason is that each dlls and app initialize the own druntime (and stacktrace modules) though the Windows' DBGHELP does not allow to initialize *more than once*. https://msdn.microsoft.com/en-us/library/windows/desktop/ms681351(v=vs.85).aspx So the latter initialization for app fails, leaving the initialized flag false. QUICK WORKAROUND: at core.sys.windows.stacktrace: shared static this() dbghelp.SymCleanup(hProcess); // @@@ ADD if (!dbghelp.SymInitialize(hProcess, generateSearchPath().ptr, TRUE)) return; NOTE: For now, we cannot raise exceptions over DLL boundary. So I've no idea how to solve this correctly. --
[Issue 17132] New: Using DLL makes an empty stacktrace on error
https://issues.dlang.org/show_bug.cgi?id=17132 Issue ID: 17132 Summary: Using DLL makes an empty stacktrace on error Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: j...@red.email.ne.jp I am working with DLL in Windows. When some error raises, the stacktrace always generates empty. Probably, this is a Windows issue. --
[Issue 8471] std.stdio.readf should be @trusted
https://issues.dlang.org/show_bug.cgi?id=8471 --- Comment #13 from Jakub Łabaj--- I understand now, thanks! You can find my profile here: https://github.com/byebye. I've create a simple PR: https://github.com/dlang/phobos/pull/5040 for similar issue involving formattedRead, where I was wondering if I should restrict arguments to pointers. So it seems the solution would be exactly the same in both cases. --
[Issue 8471] std.stdio.readf should be @trusted
https://issues.dlang.org/show_bug.cgi?id=8471 --- Comment #12 from Andrei Alexandrescu--- @Jakub, what's your github id? thx! --
[Issue 8471] std.stdio.readf should be @trusted
https://issues.dlang.org/show_bug.cgi?id=8471 --- Comment #11 from Andrei Alexandrescu--- Oh, sorry. The idea is to leave readf unqualified and let the compiler infer whether it's safe or not. In this particular case I see there's a simple solution - just add a constraint to it making sure all parameters are pointers. Something like: uint readf(Data...)(in char[] format, Data data) if (allSatisfy!(isPointer, Data); Then the only way to call readf is with pointers, which eliminates the possibility of shenanigans. --
[Issue 8471] std.stdio.readf should be @trusted
https://issues.dlang.org/show_bug.cgi?id=8471 --- Comment #10 from Jakub Łabaj--- I know how to create PRs, I've already created some. What I mean is I'm not sure how you see the solution, e.g. '@safe function with a small @trusted core', could elaborate on this, please? --
[Issue 17131] New: [Reg 2.074] Fiber.state collides with differently attributed function in derived class
https://issues.dlang.org/show_bug.cgi?id=17131 Issue ID: 17131 Summary: [Reg 2.074] Fiber.state collides with differently attributed function in derived class Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: c...@dawg.eu CC: slud...@outerproduct.org cat > bug.d << CODE import core.thread; class TaskFiber : Fiber { this() { super({}); } State state() @trusted const nothrow { return super.state; } } CODE dmd -c -o- bug bug.d(7): Error: function bug.TaskFiber.state cannot override final function core.thread.Fiber.state Introduced (triggered?) by changing the attributes on core.thread.Fiber.state(). https://github.com/dlang/druntime/pull/1726 Currently breaks vibe.d and a couple of projects on https://ci.dawg.eu. --
[Issue 17130] [Reg 2.074] ambiguous implicit super call when inheriting core.sync.mutex.Mutex
https://issues.dlang.org/show_bug.cgi?id=17130 Martin Nowakchanged: What|Removed |Added Hardware|x86_64 |All OS|Linux |All Severity|enhancement |regression --- Comment #1 from Martin Nowak --- Currently breaks vibe.d and a couple of projects on ci.dawg.eu. --
[Issue 8471] std.stdio.readf should be @trusted
https://issues.dlang.org/show_bug.cgi?id=8471 --- Comment #9 from Andrei Alexandrescu--- (In reply to Jakub Łabaj from comment #8) > Sorry, I'm not sure what you mean by that - what are the next steps to do > here? I think Razvan Nitu has reached out to you on how to go about creating PRs. --
[Issue 17130] New: [Reg 2.074] ambiguous implicit super call when inheriting core.sync.mutex.Mutex
https://issues.dlang.org/show_bug.cgi?id=17130 Issue ID: 17130 Summary: [Reg 2.074] ambiguous implicit super call when inheriting core.sync.mutex.Mutex Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: c...@dawg.eu cat > bug.d << CODE import core.sync.mutex : Mutex; class MyMutex : Mutex { } CODE dmd -c -o- bug /home/dawg/Code/D/bug.d(3): Error: core.sync.mutex.Mutex.__ctor called with argument types () matches both: /home/dawg/dlang/dmd-master-2017-01-28/linux/bin64/../../src/druntime/import/core/sync/mutex.di(21): core.sync.mutex.Mutex.this() and: /home/dawg/dlang/dmd-master-2017-01-28/linux/bin64/../../src/druntime/import/core/sync/mutex.di(25): core.sync.mutex.Mutex.this() /home/dawg/Code/D/bug.d(3): Error: class bug.MyMutex cannot implicitly generate a default ctor when base class core.sync.mutex.Mutex is missing a default ctor Introduced by https://github.com/dlang/druntime/issues/1728 or https://github.com/dlang/druntime/issues/1726. This is arguable a dmd bug, but it easily breaks any Mutex sub-class right now. --
[Issue 17057] trait "allMembers" incorrectly includes imports
https://issues.dlang.org/show_bug.cgi?id=17057 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/912252b50277b95964981ef197d708db662b6554 Fix Issue 17057 - Added test file https://github.com/dlang/dmd/commit/6280bb4437c05f418e852dad65c7f09ae2b43dd7 Merge pull request #6505 from RazvanN7/Issue_17057 Fix Issue 17057 - trait allMembers incorrectly includes imports --
[Issue 17057] trait "allMembers" incorrectly includes imports
https://issues.dlang.org/show_bug.cgi?id=17057 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 17129] New: class-nested alias of free function can't be called from const-methods
https://issues.dlang.org/show_bug.cgi?id=17129 Issue ID: 17129 Summary: class-nested alias of free function can't be called from const-methods Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: dl...@supradigital.org The following code fails with this compiler message: main.d(11): Error: template main.C.filter!((a) => a != 0).filter cannot deduce function from argument types !()(int[]) const, candidates are: /usr/include/dmd/phobos/std/algorithm/iteration.d(1057): main.C.filter!((a) => a != 0).filter(Range)(Range range) if (isInputRange!(Unqual!Range)) import std.algorithm; alias filterZeros2 = filter!(a=>a!=0); class C { alias filterZeros = filter!(a=>a!=0); void doCount ( ) const { filterZeros([1,2,3]).count; // fails filterZeros2([1,2,3]).count; // works } void doCount ( ) { filterZeros([1,2,3]).count; // works filterZeros2([1,2,3]).count; // works } } void main() {} --
[Issue 16521] Wrong code generation with switch + static foreach
https://issues.dlang.org/show_bug.cgi?id=16521 Nemanja Boric <4bur...@gmail.com> changed: What|Removed |Added CC||4bur...@gmail.com --- Comment #2 from Nemanja Boric <4bur...@gmail.com> --- I hit the same bug today: ``` import std.traits; struct S { int a, b, c, d, e, f; } void main() { S s; foreach (name; ["a", "b", "c"]) { switch (name) { foreach (i, ref field; s.tupleof) { case __traits(identifier, S.tupleof[i]): field = 0; // s.tupleof[i] = 0; works break; } default: break; } } } ``` --
[Issue 17128] Wrong destructor call, if variables declared using tuple of types.
https://issues.dlang.org/show_bug.cgi?id=17128 ag0ae...@gmail.com changed: What|Removed |Added Keywords||wrong-code CC||ag0ae...@gmail.com --
[Issue 17128] New: Wrong destructor call, if variables declared using tuple of types.
https://issues.dlang.org/show_bug.cgi?id=17128 Issue ID: 17128 Summary: Wrong destructor call, if variables declared using tuple of types. Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: critical Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: jappleg...@gmail.com import std.stdio; struct Foo { int val = 0; ~this() { writefln("destruct %s", val); } } void bar(ARGS...)() { ARGS args; args[0].val = 1; writefln("val = %s", args[0].val); } void main() { bar!Foo(); } Excpected output: val = 1 destruct 1 But got: destruct 0 val = 1 It seems that the compiler destructs 'args' immediately after definition, not at the end of the function. --
[Issue 17127] New: bad example code for std.concurrency.Generator
https://issues.dlang.org/show_bug.cgi?id=17127 Issue ID: 17127 Summary: bad example code for std.concurrency.Generator Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: ag0ae...@gmail.com Found by Profile Anaysis who posted to D.learn: http://forum.dlang.org/post/vlvqmzrfvqmxzsfxp...@forum.dlang.org The example code for std.concurrency.Generator [1] throws an OwnerTerminated exception. The code: import std.concurrency; import std.stdio; void main() { auto tid = spawn( { while (true) { writeln(receiveOnly!int()); } }); auto r = new Generator!int( { foreach (i; 1 .. 10) yield(i); }); foreach (e; r) { tid.send(e); } } The exception gets thrown because the spawned thread still tries to receive ints after the main thread has finished. The example code should be fixed. [1] https://dlang.org/library/std/concurrency/generator.html --
[Issue 12894] Make extern(Windows) behave like extern(C) on non-Windows systems
https://issues.dlang.org/show_bug.cgi?id=12894 anonymous4changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #5 from anonymous4 --- UnixODBC uses windows calling convention on non-Windows systems. --
[Issue 17118] [REG 2.074a] iasm64.d in test suite with with -g reveals a regression
https://issues.dlang.org/show_bug.cgi?id=17118 b2.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from b2.t...@gmx.com --- contact uplink.co...@googlemail.com to get a clean report. This was reported indirectly. --
[Issue 14932] The language specification does not define what the shared attribute does
https://issues.dlang.org/show_bug.cgi?id=14932 anonymous4changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=16198 --
[Issue 16198] Language specification should have a page about concurrency
https://issues.dlang.org/show_bug.cgi?id=16198 anonymous4changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14932 --