[Issue 17128] Wrong destructor call, if variables declared using tuple of types.

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17128 ag0ae...@gmail.com changed: What|Removed |Added Keywords||wrong-code CC|

[Issue 16521] Wrong code generation with switch + static foreach

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16521 Nemanja Boric <4bur...@gmail.com> changed: What|Removed |Added CC||4bur...@gmail.com ---

[Issue 17129] New: class-nested alias of free function can't be called from const-methods

2017-01-30 Thread via Digitalmars-d-bugs
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

[Issue 14932] The language specification does not define what the shared attribute does

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14932 anonymous4 changed: What|Removed |Added See Also|

[Issue 17118] [REG 2.074a] iasm64.d in test suite with with -g reveals a regression

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17118 b2.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Issue 16198] Language specification should have a page about concurrency

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16198 anonymous4 changed: What|Removed |Added See Also|

[Issue 12894] Make extern(Windows) behave like extern(C) on non-Windows systems

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12894 anonymous4 changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment

[Issue 17127] New: bad example code for std.concurrency.Generator

2017-01-30 Thread via Digitalmars-d-bugs
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

[Issue 17128] New: Wrong destructor call, if variables declared using tuple of types.

2017-01-30 Thread via Digitalmars-d-bugs
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

[Issue 17057] trait "allMembers" incorrectly includes imports

2017-01-30 Thread via Digitalmars-d-bugs
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

[Issue 17057] trait "allMembers" incorrectly includes imports

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17057 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 17130] New: [Reg 2.074] ambiguous implicit super call when inheriting core.sync.mutex.Mutex

2017-01-30 Thread via Digitalmars-d-bugs
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

[Issue 8471] std.stdio.readf should be @trusted

2017-01-30 Thread via Digitalmars-d-bugs
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

[Issue 8471] std.stdio.readf should be @trusted

2017-01-30 Thread via Digitalmars-d-bugs
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 8471] std.stdio.readf should be @trusted

2017-01-30 Thread via Digitalmars-d-bugs
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

[Issue 17131] New: [Reg 2.074] Fiber.state collides with differently attributed function in derived class

2017-01-30 Thread via Digitalmars-d-bugs
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

[Issue 17130] [Reg 2.074] ambiguous implicit super call when inheriting core.sync.mutex.Mutex

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17130 Martin Nowak changed: What|Removed |Added Hardware|x86_64 |All OS|Linux

[Issue 8471] std.stdio.readf should be @trusted

2017-01-30 Thread via Digitalmars-d-bugs
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

2017-01-30 Thread via Digitalmars-d-bugs
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

[Issue 17132] Using DLL makes an empty stacktrace on error

2017-01-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17132 j...@red.email.ne.jp changed: What|Removed |Added Keywords||dll --

[Issue 17132] New: Using DLL makes an empty stacktrace on error

2017-01-30 Thread via Digitalmars-d-bugs
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

[Issue 17132] Using DLL makes an empty stacktrace on error

2017-01-30 Thread via Digitalmars-d-bugs
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*.