[Issue 15885] float serialized to JSON loses precision

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15885

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/7a486d9d038448595c74aa4ef4bd7d9e952a4b64
Fix issue 15885 - numeric values serialized to JSON lose precision.

https://github.com/dlang/phobos/commit/f4ad734aad6e3b2dd4881508d2b15eebb732a26c
Merge pull request #4345 from tsbockman/issue-15885-tsb

Fix issue 15885 - float serialized to JSON loses precision

--

[Issue 15885] float serialized to JSON loses precision

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15885

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16107

--- Comment #1 from b2.t...@gmx.com ---
definition of Foo can be reduced to

class Foo
{
alias TreeItemType = typeof(this);

TreeItemSiblings!TreeItemType _siblings;// remove this decl
TreeItemChildren!TreeItemType _children;// or this one  : OK
}
The content was initially a mixin template, which explains why it was
incoherant...anyway still the ICE.

--

[Issue 16107] New: [ICE] - Internal error: backend/cgcod.c 2297

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16107

  Issue ID: 16107
   Summary: [ICE] - Internal error: backend/cgcod.c 2297
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

The following code, compiled with DMD 2.071.1-b2 crashes the compiler:

===
import std.stdio, std.traits;

struct TreeItemChildren(T){}

struct TreeItemSiblings(T){}

class Foo
{
enum isStruct = is(typeof(this) == struct);
static if (isStruct)
alias TreeItemType = typeof(this)*;
else
alias TreeItemType = typeof(this);

TreeItemSiblings!TreeItemType _siblings;// remove this decl
TreeItemChildren!TreeItemType _children;// or this one  : OK
}

template Bug(T)
{
bool check()
{
bool result;
import std.meta: aliasSeqOf;
import std.range: iota;

foreach(i;  aliasSeqOf!(iota(0, T.tupleof.length)))
{
alias MT = typeof(T.tupleof[i]);
static if (is(MT == struct))
result |= Bug!MT;   // result = result | ... : OK
if (result) break; // remove this line   : OK

}
return result;
}
enum Bug = check();
}

void main()
{
assert(!Bug!Foo);
}

produces 

> Internal error: backend/cgcod.c 2297

The comments in the code indicates each time that the bug doesn't happen when
the stuff is commented.

--

[Issue 15371] __traits(getMember) should bypass the protection

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15371

--- Comment #4 from b2.t...@gmx.com ---
In the meantime, when the trait code is for a struct or a class it's possible
to use its '.tupleof' property. It's not affected by the visibility.

Instead of all member:

import std.meta: aliasSeqOf;
import std.range: iota;
foreach(i;  aliasSeqOf!(iota(0, T.tupleof.length)))
{
alias MT = typeof(T.tupleof[i]);
...
}
This is not exactly the same but when the trait code is to inspect the variable
types or UDAs it works fine.

--

[Issue 16090] popFront generates out-of-bounds array index on corrupted utf-8 strings

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16090

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/e1af1b0b51ea9f29d4ff8076d73c03ba10bfc73c
fix issue 16090 - popFront generates out-of-bounds array index on corrupted
utf-8 strings

https://github.com/dlang/phobos/commit/279ccd7c5c8cebfb21a3138aecf7f3a85444e538
Merge pull request #4387 from aG0aep6G/16090

fix issue 16090 - popFront generates out-of-bounds array index on cor…

--

[Issue 16090] popFront generates out-of-bounds array index on corrupted utf-8 strings

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16090

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||pull
 CC||ag0ae...@gmail.com
   Assignee|nob...@puremagic.com|ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
https://github.com/dlang/phobos/pull/4387

--

[Issue 15324] symbol is already defined / size of symbol changed

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15324

Johannes Pfau  changed:

   What|Removed |Added

   Severity|critical|normal

--- Comment #7 from Johannes Pfau  ---
Reducing importance: As explained by Iain, the reported example is invalid D
code. DMD should still warn about this.

Additionally, there are cases where DMD passes template symbols multiple times
to the backend. I don't have a test case right now, but we added a workaround
for this to GDC and GDC will now compile such code. So this is no longer a
blocker for GDC.

--

[Issue 16106] Calling a fiber from itself causes hard-to-debug stack corruption

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16106

--- Comment #1 from Don  ---
To clarify: I'm asking for the situation where you call a fiber which is not in
state HOLD, to be detected even when compiled without contracts.

I'm not asking for fiber.call() to ever be a no-op.

Ie, fiber.call() should either switch to a different fiber, or else it should
halt execution. It should never cause stack corruption.

--

[Issue 16084] Linker error, not failed compilation, with interface final function calling virtual template function

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16084

Jack Stouffer  changed:

   What|Removed |Added

   Keywords||accepts-invalid
Summary|Linker error with interface |Linker error, not failed
   |final function calling  |compilation, with interface
   |virtual function|final function calling
   ||virtual template function

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15094

Johan Engelen  changed:

   What|Removed |Added

 CC||jbc.enge...@gmail.com

--

[Issue 16084] Linker error with interface final function calling virtual function

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16084

Jack Stouffer  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #4 from Jack Stouffer  ---
Ok, I am changing this to an improved error message request. Also, IMO it
should be mentioned on the interface page of the spec that template functions
that don't use the interface template parameters are auto marked as final.

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15094

--- Comment #6 from Eyal Lotem  ---
Even after applying the PR
(https://github.com/D-Programming-Language/dmd/pull/5215):

```
struct S { int i; }
S s;

unittest {
import std.meta : Alias;

alias GetMember1 =
Alias!(__traits(getMember, mixin(__MODULE__), "s"));
alias GetMember2 =
Alias!(__traits(getMember, GetMember1, "i"));
alias GetMember3 =
Alias!(__traits(getMember,
__traits(getMember, mixin(__MODULE__), "s"),
"i"));

// Works:
auto a1 = 
// Fails:
auto a2 = 
// Fails:
auto a3 = 
// Works:
auto a4 =
&__traits(getMember,
  __traits(getMember, mixin(__MODULE__), "s"),
  "i");
}
```

fails (in a2, a3).

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15094

Eyal Lotem  changed:

   What|Removed |Added

 CC||eyal.lo...@gmail.com

--- Comment #5 from Eyal Lotem  ---
Even after applying the PR
(https://github.com/D-Programming-Language/dmd/pull/5215):

```
struct S { int i; }
S s;

unittest {
import std.meta : Alias;

alias GetMember1 =
Alias!(__traits(getMember, mixin(__MODULE__), "s"));
alias GetMember2 =
Alias!(__traits(getMember, GetMember1, "i"));
alias GetMember3 =
Alias!(__traits(getMember,
__traits(getMember, mixin(__MODULE__), "s"),
"i"));

// Works:
auto a1 = 
// Fails:
auto a2 = 
// Fails:
auto a3 = 
// Works:
auto a4 =
&__traits(getMember,
  __traits(getMember, mixin(__MODULE__), "s"),
  "i");
}
```

fails (in a2, a3).

--

[Issue 16106] New: Calling a fiber from itself causes hard-to-debug stack corruption

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16106

  Issue ID: 16106
   Summary: Calling a fiber from itself causes hard-to-debug stack
corruption
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: clugd...@yahoo.com.au

If you are in fiber `f`, and you call `f.call()`, then you are switching the
context to yourself.
There is an `in` contract in Fiber.call() which is meant to prevent this:
assert( m_state == State.HOLD );

That assert will fail, because the fiber is running. But if contracts are
disabled, then execution will continue anyway.

Conceptually, switching context to yourself is a no-op. The function could
simply return. I'm not sure that would be a good idea, but it's certainly
possible. And it *almost* behaves that way. The function fiber_switchContext()
pushes the registers onto the existing stack, then pops them from the new
stack.
In this case, the old stack and new stack are the same. Except that the new
stack pointer is the top of the new stack *before the pushes were made*.

So, it loads the registers from the completely wrong place. If you're lucky,
you get a segfault. If you don't, you'll end up in a completely unrelated
place. Either way it is quite difficult to diagnose why it has happened.

Admittedly, this only happens after an 'in' contract violation. But I think we
should do something a bit more robust.

The check for ``m_state == State.HOLD`` is not expensive (one CMP and a
predictable branch). It should be moved out of the contract into the function
body. The consequences of a totally corrupt stack are _extremely_ severe. It's
worth sacrificing a single clock cycle to prevent this debugging nightmare.

--

[Issue 16073] Ranges without opDollar not supported

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16073

--- Comment #2 from Jack Stouffer  ---
https://github.com/dlang/phobos/pull/4383

--

[Issue 16085] wrong visibility warning for overloaded alias symbol

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16085

--- Comment #9 from Martin Nowak  ---
(In reply to Walter Bright from comment #8)
> > The member "reallocate" should effectively hide the private import, yet the
> > deprecation message still appears.
> 
> The private import is hidden. The alias is not.

Don't quite get that comment. Imports are private by default, so are the
selectively imported symbol aliases.

Already figured out what's wrong with the overload implementation in
symbolIsVisible, just need to find time to fix it.

--

[Issue 16105] `is` fails for init value of struct with float

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16105

--- Comment #2 from Don  ---
This isn't a codegen bug per se, but is rather a design bug.

It happens because float.init is a signalling NaN. We should change it to be a
quiet NaN. Using signalling NaNs seemed like a good idea at the time but it
turns out that the hardware support for it just isn't good enough.
Even on x86, Intel and AMD CPUs behave differently. And on other CPUs it is
even worse.
The situation at present is, the intended behaviour is a bit broken on some
platforms, and totally broken on others. It is impossible to fix it.

It is entirely my fault. When Walter released the backend I did this signalling
NaN experiment that I had always wanted to do. I think it was my first compiler
patch ever. It was a mistake. A failed experiment. We need to roll it back.

--

[Issue 16094] error: overlapping slice assignment (CTFE)

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16094

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull
   Hardware|x86 |All
 OS|Windows |All
   Severity|minor   |normal

--- Comment #1 from Kenji Hara  ---
https://github.com/dlang/dmd/pull/5827

--

[Issue 16100] [REG 2.069] Error with -O of struct enumeration value and comma operator

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16100

--- Comment #2 from David Nadlinger  ---
It seems that versions prior to 2.069 at least statically rejected the code.
Even though this was probably in error, it's still better than an ICE, so
marking as regression.

--

[Issue 16100] [REG 2.069] Error with -O of struct enumeration value and comma operator

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16100

David Nadlinger  changed:

   What|Removed |Added

 CC||c...@klickverbot.at
Summary|Error with -O of struct |[REG 2.069] Error with -O
   |enumeration value and comma |of struct enumeration value
   |operator|and comma operator
   Severity|normal  |regression

--

[Issue 16093] Trivial case of passing a template function to another template function doesn't compile

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16093

--- Comment #4 from Max Samukha  ---
(In reply to Max Samukha from comment #0)
> void bar(alias f)() {
> f();
> }
> 
> void main() {
> void f()() {
> }
> bar!f();
> }
> 
> Error: function test.main.f!().f is a nested function and cannot be accessed
> from test.bar!(f).bar
> 

Note that it compiles ok with -inline.

--

[Issue 16105] `is` fails for init value of struct with float

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16105

--- Comment #1 from Marc Schütz  ---
Addendum: It works correctly with LDC, so it's probably a codegen bug.

--

[Issue 16105] New: `is` fails for init value of struct with float

2016-05-31 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16105

  Issue ID: 16105
   Summary: `is` fails for init value of struct with float
   Product: D
   Version: D2
  Hardware: x86_64
   URL: https://forum.dlang.org/post/jzgwikubjfmlcdgpierj@foru
m.dlang.org
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: schue...@gmx.net

The following test case only prints "B: works", although the first comparison
should succeed, too:

import std.stdio;

struct Foo
{
int x;
float f;
}

void main()
{
Foo foo;
if(foo is Foo.init) "A: doesn't work".writeln;
foo = Foo();
if(foo is Foo.init) "B: works".writeln;
}

Found by ArturG:
https://forum.dlang.org/post/jzgwikubjfmlcdgpi...@forum.dlang.org

--