[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 b2.t...@gmx.com ---
The OP hasn't well noted that's only the **debug** build which is affected.

--

[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
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

According to http://forum.dlang.org/post/yhnfnliteruwixsae...@forum.dlang.org
and http://forum.dlang.org/post/byhninhkueqpscawf...@forum.dlang.org DMD
suffered anywhere between a 47% to 360% increase in compile times.

My largest project actually saw a decrease in compile times, so we have to
solicit the community for examples.

--

[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||safety0ff.b...@gmail.com

--- Comment #4 from safety0ff.bugz  ---
(In reply to Walter Bright from comment #3)
> 
> And you'd be right.
> 
> https://github.com/D-Programming-Language/dmd/pull/4921

Does this fix the struct case as well?

struct S { void foo() { asm { naked; ret; } } }

I just hit this bug.

--

[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
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: j...@red.email.ne.jp

I found this when verifying the struct sizes for Win32-x64.
Some of the buffer sizes are pseudo values, as its comment says.

I'll send a PR.

--

[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 from j...@red.email.ne.jp ---
I confirmed this with dmd 2.068 and -m64 mode in Windows.

So -allinst option works.

--

[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, if that fails, calls
the derived class's in contract?

>> But even better would be to add debugging output to I's in contract.
> 
> Parameter contains garbage, I don't think there is any need to print it.

How do you establish that the parameter contains garbage (as opposed to any
other possible cause of what we're observing) without printing it?

--

[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
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: jv_vor...@msn.com

There's no implementation for a cleared allocation (calloc). Why is that?

--

[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 to std.encoding
* less overengineering

https://github.com/D-Programming-Language/phobos/pull/3870 rework

Don't use top-level selective import in std.math because of DMD issue 314.

some quickfur comments

whitespace

remove used import

steven suggestion

utfBom

andrei nitpicks

andrei null

--

[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 money on the table. If you
> were sure that no one was using this for duplication, then you would have
> taken my bet.

I don't gamble. Especially when it's impossible to win.

(Let's end off-topic here.)

--

[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 one was using this for duplication, then you would have taken my
bet.

--

[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

--- Comment #7 from Jack Stouffer  ---
(In reply to sigod from comment #4)
> I bet no one uses `array()` for duplicating
> arrays.

Maybe, maybe not. But I'd bet $500 that people rely on the functionality and
don't know it. If this is changed you'll have people suddenly wondering why
their arrays are getting filled garbage data.

With a function as popular as std.array.array, I'd say this change is way too
dangerous.

--

[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
  Keywords: link-failure
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

/// test.d ///
struct S()
{
void delegate() d;
}

S!() f_Ds(U=D*)()
{
static if (is(U == struct))
return S!()
(
{
foreach (i, field; U.init.tupleof)
f_Ds!(typeof(field))();
}
);

static if (is(U V : V*))
return f_Ds!V();
}

void f_E()()
{
auto f = S!()
(
{
enum x = is(typeof(f_Ds!(D*)()));
f_Ds!(D*)();
}
);
}

struct A
{
D* d;
}

struct B
{
}

struct C
{
A a;
B b;
}

struct D
{
C c;
}

void main()
{
f_E();
f_Ds!D();
}
//

Linux  , DMD 2.068.0, with-debug: OK
Linux  , DMD 2.068.0, without -debug: OK
Linux  , DMD 2.069.0, with-debug: OK
Linux  , DMD 2.069.0, without -debug: Link error

Windows, DMD 2.067.0, with-debug: OK
Windows, DMD 2.067.0, without -debug: OK
Windows, DMD 2.068.0, with-debug: OK
Windows, DMD 2.068.0, without -debug: Link error

Bisection attempts point towards master/stable branch merges (i.e. nothing
useful).

It is probably a latent heisenbug triggered by other changes.

Downstream issue: https://github.com/CyberShadow/Digger/issues/36

--

[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 processor specific behavior

https://github.com/dlang/phobos/commit/aa8cf8646f1cedb058a51465da5b962f98b42cd7
Merge pull request #4268 from JackStouffer/issue15973

[Issue 15973]: nextPow2 and truncPow2 rely on processor specific …

--

[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
 Resolution|--- |FIXED

--

[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 templates are
ignored

There can be 3 types of AST node in `importedScopes`: `Module`, `TemplateMixin`
and `Nspace`.
`MixinTemplate` can also introduce imports, so we need to look into them when
doing the second
search pass.

https://github.com/dlang/dmd/commit/1231eacba1fedc38bf617654b1ba266f95edf345
Merge pull request #5724 from mathias-lang-sociomantic/fix-15925-stable

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

--

[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 contract fails.  (Though this
> is down to another issue, bug 6857.)

Thanks, I still can't remember how does current implementation of D contracts
work.

> But even better would be to add debugging output to I's in contract.

Parameter contains garbage, I don't think there is any need to print it.

--

[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 #3 from Stewart Gordon  ---
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 contract fails.  (Though this is
down to another issue, bug 6857.)

But even better would be to add debugging output to I's in contract.

--
import std.stdio;

interface I
{
void f(int i)
in {
writeln(i);
assert(i == 5);
}
}

class C : I
{
void f(int i)
in { assert (false); }
body { }
}

void main()
{
I i = new C;
i.f(5);
}
--
4202755

core.exception.AssertError@bz15984.d(14): Assertion failure

0x00402D3B
0x00402103
0x00403EA7
0x00403DA8
0x0040270F
0x769DD4D1 in BaseThreadInitThunk
0x77201593 in RtlInitializeExceptionChain
0x77201566 in RtlInitializeExceptionChain
--

--

[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 change this issue importance until correct
> REGRESSION behavior case issue is filed.

This issue is a REGRESSION, dmd 2.070 correctly passes parameters to interface
contracts.

--

[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

--- Comment #1 from Denis Shelomovskij  ---
vibe.d 0.7.28+ now fails in non-release builds because of this issue. It didn't
fail before, so there is a REGRESSION is dmd 2.071. Probably these contracts
wasn't called before and current issue isn't really a REGRESSION but I will
still temporary change this issue importance until correct REGRESSION behavior
case issue is filed.

--

[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||verylonglogin@gmail.com

--- Comment #6 from Denis Shelomovskij  ---
Please reopen if this is a cumulative issue as interface contracts are still
broken, they can't access parameters (see Issue 15984).

--

[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
  Keywords: contracts, wrong-code
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: verylonglogin@gmail.com
Blocks: 7517

This code should run fine:
---
interface I
{
void f(int i)
in { assert(i == 5); } // Fails
}

class C : I
{
void f(int i)
in { } // To call contract
body { }
}

void main()
{
I i = new C;
i.f(5);
}
---

Note: `(new C).f(5)` fails too but let's support correct contract
implementation (i.e. contract is called based on static type) in testcase.

--

[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 (isInputRange!R && !hasIndirections!(ElementType!R))
> {
> import std.array: array;
> import std.exception: assumeUnique;
> return assumeUnique(range.array);
> }
> 

Missing imports:

import std.range: ElementType, isInputRange;
import std.traits: hasIndirections;


--

[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 array. Changing that is a breaking change.

> Function called `array` for a reason. Because it gives you array where you
> have only an input range. It doesn't make sense to do anything if you
> already have an array. In normal code you will never call `array` for array.

Here's a little generic function that relies on std.array.array's current
behavior:

immutable(ElementType!R)[] toImmutableArray(R)(R range)
if (isInputRange!R && !hasIndirections!(ElementType!R))
{
import std.array: array;
import std.exception: assumeUnique;
return assumeUnique(range.array);
}


--

[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
> call it on an int[], I can rely on the new array being independent from the
> original one. I can alter elements without affecting the original. I can
> cast it to immutable(int)[] without running into undefined behavior when the
> original is altered.

One of the first things that I learned in D is that you have `dup` and `idup`
"properties" for this. I bet no one uses `array()` for duplicating arrays.

> I'm not saying that this is the best behavior for a function called "array",
> but that's how it's documented and how it works. Changing it now would be a
> serious breaking change.

Function called `array` for a reason. Because it gives you array where you have
only an input range. It doesn't make sense to do anything if you already have
an array. In normal code you will never call `array` for array.

--

[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 independent from the original
one. I can alter elements without affecting the original. I can cast it to
immutable(int)[] without running into undefined behavior when the original is
altered.

I'm not saying that this is the best behavior for a function called "array",
but that's how it's documented and how it works. Changing it now would be a
serious breaking change.

--

[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 ag0ae...@gmail.com ---
This would be a serious breaking change. The documentation says that the
function allocates and copies.

--

[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
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: sigod.m...@gmail.com

import std.array : array;
int[] a = [1, 2, 3];
assert(a.ptr == array(a).ptr); // fails

I think for dynamic arrays `array()` should just return provided value without
doing anything.

--

[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* tls;

void main()
{
foreach (ref sg; SectionGroup)
{
foreach (rng; sg.gcRanges)
printf("glob: beg = %p  end = %p\n", rng.ptr, rng.ptr +
rng.length);
}
if (auto arr = initTLSRanges()) 
foreach (rng; *arr)
printf("tls:  beg = %p  end = %p\n", rng.ptr, rng.ptr +
rng.length);

printf(" = %p\n", );
}

It prints:
glob: beg = 0x6299f0  end = 0x62e3a8
tls:  beg = 0x7fd37dfdb717  end = 0x7fd37dfdba40
 = 0x7fd37dfdb710

--