[Issue 15988] [REG v2.070] Massive Compile Time Slowdown

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15988 b2.t...@gmx.com changed: What|Removed |Added CC||b2.t...@gmx.com --- Comment #1 from

[Issue 15988] New: [REG v2.070] Massive Compile Time Slowdown

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15988 Issue ID: 15988 Summary: [REG v2.070] Massive Compile Time Slowdown Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression

[Issue 13147] Wrong codegen for thisptr in naked extern (C++) methods

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13147 safety0ff.bugz changed: What|Removed |Added CC|

[Issue 15987] New: core.sys.windows.msacm remains pseudo definitions

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15987 Issue ID: 15987 Summary: core.sys.windows.msacm remains pseudo definitions Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal

[Issue 15985] [REG2.068/2.069] Code doesn't link unless compiled with -debug

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15985 j...@red.email.ne.jp changed: What|Removed |Added CC||j...@red.email.ne.jp --- Comment #1

[Issue 15984] Interface contracts retrieve garbage instead of parameters

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15984 --- Comment #5 from Stewart Gordon --- (In reply to Denis Shelomovskij from comment #4) > Thanks, I still can't remember how does current implementation of D > contracts work. It looks like it calls the base class's in contract and,

[Issue 15986] New: [std.experimental.allocator.mallocator] calloc?

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15986 Issue ID: 15986 Summary: [std.experimental.allocator.mallocator] calloc? Product: D Version: D2 Hardware: All URL: http://dlang.org/phobos/ OS: All

[Issue 314] [module] Static, renamed, and selective imports are always public

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=314 --- Comment #57 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/3d37aee77d12e13b970a84d3e06101e5fd04a00c Byte Order Mark (BOM) handling functions rewrite * move

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #10 from sigod --- (In reply to Jack Stouffer from comment #9) > (In reply to sigod from comment #8) > > I'm not betting on anything. It was a figure of speech. > > The best way to call someone's bluff is to put

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #9 from Jack Stouffer --- (In reply to sigod from comment #8) > I'm not betting on anything. It was a figure of speech. The best way to call someone's bluff is to put money on the table. If you were sure that no

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #8 from sigod --- I'm not betting on anything. It was a figure of speech. --

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15982 Jack Stouffer changed: What|Removed |Added CC||j...@jackstouffer.com

[Issue 15985] New: [REG2.068/2.069] Code doesn't link unless compiled with -debug

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15985 Issue ID: 15985 Summary: [REG2.068/2.069] Code doesn't link unless compiled with -debug Product: D Version: D2 Hardware: All OS: All Status: NEW

[Issue 15973] nextPow2 and truncPow2 rely on processor specific behavior

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15973 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/6d8f0b8285c67422f0463b30d5afc9c82c6d3dfb Fixed Issue 15973: nextPow2 and truncPow2 rely on

[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15925 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15925 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/5c7b6eac2dc7d0ba65d81d10ff7a18fe19313718 [REG 2.071] Fix Issue 15925 - Import declaration from mixin

[Issue 15984] Interface contracts retrieve garbage instead of parameters

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15984 --- Comment #4 from Denis Shelomovskij --- (In reply to Stewart Gordon from comment #3) > The posted code doesn't show the problem as I try (DMD 2.071.0 Windows). In > order to test it, one needs to make sure C's

[Issue 15984] Interface contracts retrieve garbage instead of parameters

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15984 Stewart Gordon changed: What|Removed |Added CC||s...@iname.com --- Comment

[Issue 15984] Interface contracts retrieve garbage instead of parameters

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15984 --- Comment #2 from Denis Shelomovskij --- (In reply to Denis Shelomovskij from comment #1) > Probably these > contracts wasn't called before and current issue isn't really a REGRESSION > but I will still temporary

[Issue 15984] Interface contracts retrieve garbage instead of parameters

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15984 Denis Shelomovskij changed: What|Removed |Added Severity|major |regression

[Issue 7517] Interface contracts broken

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=7517 Denis Shelomovskij changed: What|Removed |Added CC|

[Issue 7517] Interface contracts broken

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=7517 Denis Shelomovskij changed: What|Removed |Added Depends on||15984 --

[Issue 15984] New: Interface contracts retrieve garbage instead of parameters

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15984 Issue ID: 15984 Summary: Interface contracts retrieve garbage instead of parameters Product: D Version: D2 Hardware: All OS: All Status: NEW

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #6 from ag0ae...@gmail.com --- (In reply to ag0aep6g from comment #5) > Here's a little generic function that relies on std.array.array's current > behavior: > > immutable(ElementType!R)[] toImmutableArray(R)(R range) > if

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #5 from ag0ae...@gmail.com --- (In reply to sigod from comment #4) > I bet no one uses `array()` for duplicating > arrays. I don't think betting on these things is a good course of action. The function is documented to allocate a new

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #4 from sigod --- (In reply to ag0aep6g from comment #3) > (In reply to sigod from comment #2) > > It's meaningless for dynamic arrays. > > Currently std.array.array guarantees one level of duplication. So when I >

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #3 from ag0ae...@gmail.com --- (In reply to sigod from comment #2) > It's meaningless for dynamic arrays. Currently std.array.array guarantees one level of duplication. So when I call it on an int[], I can rely on the new array being

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15982 --- Comment #2 from sigod --- It's meaningless for dynamic arrays. Currently, if you change you code from ranges to arrays you have to remove use of `array()` or it just adds hidden cost. --

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15982 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #1 from

[Issue 15982] New: std.array.array treats dynamic arrays as input ranges and allocates new memory

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15982 Issue ID: 15982 Summary: std.array.array treats dynamic arrays as input ranges and allocates new memory Product: D Version: D2 Hardware: All OS: All

[Issue 15975] TLS not scanned correctly for main thread

2016-05-02 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15975 --- Comment #2 from Rainer Schuetze --- Sorry, screwed up the test completely. It is not the variable that is misaligned, but the range scanned by the GC. Use this test program: import core.stdc.stdio; import rt.sections; void*