[Issue 18534] Wrong code for ?: operator when compiling with -O

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18534

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8052

--

[Issue 18199] Error with lambda in struct initializer

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18199

--- Comment #8 from John Belmonte  ---
https://github.com/dlang/dmd/pull/8051

--

[Issue 18630] New: std.math must CTFE

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18630

  Issue ID: 18630
   Summary: std.math must CTFE
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

Every single function in std.math must CTFE.

At very least, let's start with pow, log, exp, sin/cos and friends...

Curves exist. Populating tables with curve data is a thing that I *constantly*
want to do.

I usually workaround with a static constructor that pre-computes tables at
startup, but that only solves some subset of cases. When I want those tables to
interact with other CTFE code, I'm blocked.

--

[Issue 18282] [Scope][DIP1000]Assignment of local variable to `scope` variable not recognized by compiler

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18282

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

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--

[Issue 18282] [Scope][DIP1000]Assignment of local variable to `scope` variable not recognized by compiler

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18282

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

https://github.com/dlang/dmd/commit/2dbc2bd85d5e5a55a3bcbf362c60cb0648102a73
fix Issue 18282 part 2

https://github.com/dlang/dmd/commit/bbe466b97fe5d2fa9f2914937f42079a987579d2
Merge pull request #8045 from WalterBright/fix18282-2

fix Issue 18282 part 2
merged-on-behalf-of: Walter Bright 

--

[Issue 18199] Error with lambda in struct initializer

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18199

John Belmonte  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|j...@neggie.net

--- Comment #7 from John Belmonte  ---
Besides the code's documented case of "{}" (could be empty struct initializer
or empty parameterless function literal), there is another ambiguous case:

  static MyStruct foo = {
{ return 1 + 1; }
  };

where RHS could either be a struct initializer (with member type "int
function()") or function literal with a needless added scope.

In the "{}" case, the code sides with struct initializer.  This makes sense
since the function literal could be disambiguated in several ways (e.g. as
"function() {}").

Given that, I propose to resolve this bug as follows:

   1) document this other ambiguous case
   2) document why we side with struct literal in ambiguous cases (i.e. since
you can disambiguate function literal cases via extra syntax)
   3) change the parser to only abort struct literal look-ahead if semicolon or
return token appears at top level of curly brackets, so that struct initializer
may contain function literals

--

[Issue 18629] std.algorithm.iteration.subsitute is slow

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18629

Basile B.  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|enhancement |normal

--

[Issue 18629] New: std.algorithm.iteration.subsitute is slow

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18629

  Issue ID: 18629
   Summary: std.algorithm.iteration.subsitute is slow
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

In this benchmark i cast items as ubyte[] to prevent autodecoding. Still 2.5X
slower than a naive equivalent that uses cascaded `replace`.

```
#!dmd -O -release -inline -boundscheck=off
module runnable;

import std.stdio, std.algorithm,std.array, std.conv;

string v1(string message)
{
auto s = "{filepath}({line}:{column})[{type}]: {message}";
const string fileName = "/home/folder/folter/source.d";
const int line = 42;
const int column = 13;

s = s.replace("{filepath}", fileName);
s = s.replace("{line}", to!string(line));
s = s.replace("{column}", to!string(column));
s = s.replace("{type}", "warn");
s = s.replace("{message}", message);

return s;
}

string v3(string message)
{
auto s = "{filepath}({line}:{column})[{type}]: {message}";
const string fileName = "/home/folder/folter/source.d";
const int line = 42;
const int column = 13;
const string isError = "warn";

return cast(string) substitute(cast(ubyte[])s,
cast(ubyte[])"{filepath}", cast(ubyte[])fileName,
cast(ubyte[])"{line}", cast(ubyte[])to!string(column),
cast(ubyte[])"{column}", cast(ubyte[])to!string(column),
cast(ubyte[])"{type}", cast(ubyte[])isError,
cast(ubyte[])"{message}", cast(ubyte[])message
).array;
}

void main()
{
import std.datetime.stopwatch;
benchmark!((){v1("frst version");})(1_000_000).writeln;
benchmark!((){v3("thrd version");})(1_000_000).writeln;
}
```

gives:

[1 sec, 669 ms, 590 μs, and 8 hnsecs]
[3 secs, 5 ms, 266 μs, and 2 hnsecs]

which does not encourage to write idiomatic D code.

--

[Issue 15624] opApply with @safe and @system variants can't be used with foreach syntax

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15624

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15624] opApply with @safe and @system variants can't be used with foreach syntax

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15624

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

https://github.com/dlang/dmd/commit/70fb7cb46698ec6d6fba7efc64331cb76f73ef07
fix Issue 15624 - opApply with @safe and @system variants can't be used with
foreach syntax

https://github.com/dlang/dmd/commit/5bfa34232d104d75b189a84cc88f3dd4fc885daf
Merge pull request #8047 from WalterBright/fix15624

fix Issue 15624 - opApply with @safe and @system variants can't be us…
merged-on-behalf-of: Walter Bright 

--

[Issue 18078] [CTFE] wrong initialization of array member with inout opIndex

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18078

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
Reduced to:

---
struct S
{
int x;
version (problem) void opAssign(S o) { x = o.x; }
}

struct Foo
{
S[1] data;
ref inout(S) g() inout { return data[0]; }
this(S a) { g() = a; }
}

void main()
{
enum x = Foo(S(42));
assert(x.data[0].x == 42);
}
---

The problem disappears if you remove `opAssign` (or the inout qualifiers).

--

[Issue 18628] @disable this(this) erroneously adds `__postblit` member

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18628

johanenge...@weka.io changed:

   What|Removed |Added

   Keywords||industry

--

[Issue 18628] New: @disable this(this) erroneously adds `__postblit` member

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18628

  Issue ID: 18628
   Summary: @disable this(this) erroneously adds `__postblit`
member
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: johanenge...@weka.io

Testcase:
```
import std.traits;
import std.stdio;

void main() {
static struct S { @disable this(this); }

writeln(hasMember!(S, "__postblit")); // expected: false
writeln(hasElaborateCopyConstructor!S); // expected: false
}
```

The program prints twice "true", instead of "false".
Note that `hasElaborateCopyConstructor` does a `hasMember!(S, "__postblit")`
check, so that's the root cause of the problem.

--

[Issue 18623] Documented unittest should not allow private symbol access

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18623

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #2 from Steven Schveighoffer  ---
I would vote to close this as WONTFIX. You may want to test things inside your
unit test that have nothing to do with the example, but use the same code for
setup, and then you have to write that code twice. It's pretty easy to say //
private data, for testing only.

--

[Issue 17759] struct that attempts to implicitly cast away const causes segfault

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17759

--- Comment #3 from Steven Schveighoffer  ---
Hm... so alias this resolution needs some kind of memoization to prevent
infinite expansion. Interesting.

--

[Issue 18627] std.complex is a lot slower than builtin complex types at number crunching

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18627

--- Comment #2 from ponce  ---
I've posted there, thanks.

--

[Issue 18627] std.complex is a lot slower than builtin complex types at number crunching

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18627

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
See also: https://github.com/dlang/dmd/pull/7640

--

[Issue 18627] New: std.complex is a lot slower than builtin complex types at number crunching

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18627

  Issue ID: 18627
   Summary: std.complex is a lot slower than builtin complex types
at number crunching
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: alil...@gmail.com

BENCHMARK:

Please consider the following program:

It's just number crunching, there is no complex exponential or such function
calls.
The FFT function features complex addition, multiplication and division.

--- main.d


import std.string;
import std.datetime;
import std.datetime.stopwatch : benchmark, StopWatch;
import std.complex;
import std.stdio;
import std.math;

void main()
{
cfloat[] A = new cfloat[1024];
cdouble[] B = new cdouble[1024];
Complex!float[] C = new Complex!float[1024];
Complex!double[] D = new Complex!double[1024];
foreach(i; 0..1024)
{
// Initialize with something
A[i] = i + 0i;
B[i] = i + 0i;
C[i] = Complex!float(i, 0);
D[i] = Complex!double(i, 0);
}

void fA()
{
bench!(float, cfloat, true)(A);
}

void fB()
{
bench!(double, cdouble, true)(B);
}

void fC()
{
bench!(float, Complex!float, false)(C);
}

void fD()
{
bench!(double, Complex!double, false)(D);
}

auto r = benchmark!(fA, fB, fC, fD)(1000);
Duration fAResult = r[0];
Duration fBResult = r[1];
Duration fCResult = r[2];
Duration fDResult = r[3];
writefln("With cfloat: %s", fAResult);
writefln("With cdouble: %s", fBResult);
writefln("With Complex!float: %s", fCResult);
writefln("With Complex!double: %s", fDResult);
}

void bench(T, ComplexType, bool usingBuiltinTypes)(ComplexType[] array)
{
// forward then reverse FFT
FFT!(T, ComplexType, true, usingBuiltinTypes)(array);
FFT!(T, ComplexType, false, usingBuiltinTypes)(array);
}

// just for the benchmark purpose
private void FFT(T, ComplexType, bool direction, bool
usingBuiltinTypes)(ComplexType[] buffer) pure nothrow @nogc
{
int size = cast(int)(buffer.length);
int m = 10;

ComplexType* pbuffer = buffer.ptr;

// do the bit reversal
int i2 = cast(int)size / 2;
int j = 0;
for (int i = 0; i < size - 1; ++i)
{
if (i < j)
{
auto tmp = pbuffer[i];
pbuffer[i] = pbuffer[j];
pbuffer[j] = tmp;
}

int k = i2;
while(k <= j)
{
j = j - k;
k = k / 2;
}
j += k;
}

// compute the FFT
static if (usingBuiltinTypes)
{
ComplexType c = -1+0i;
}
else
{
ComplexType c = -1;
}
int l2 = 1;
for (int l = 0; l < m; ++l)
{
int l1 = l2;
l2 = l2 * 2;
static if (usingBuiltinTypes)
{
ComplexType u = 1+0i;
}
else
{
ComplexType u = 1;
}
for (int j2 = 0; j2 < l1; ++j2)
{
int i = j2;
while (i < size)
{
int i1 = i + l1;
ComplexType t1 = u * pbuffer[i1];
pbuffer[i1] = pbuffer[i] - t1;
pbuffer[i] += t1;
i += l2;
}
u = u * c;
}

T newImag = sqrt((1 - c.re) / 2);
static if (direction)
newImag = -newImag;
T newReal = sqrt((1 + c.re) / 2);

static if (usingBuiltinTypes)
{
c = newReal + 1.0fi * newImag;
}
else
{
c = ComplexType(newReal, newImag);
}
}

// scaling when doing the reverse transformation, to avoid being multiplied
by size
static if (!direction)
{
T divider = 1 / cast(T)size;
for (int i = 0; i < size; ++i)
{
pbuffer[i] = pbuffer[i] * divider;
}
}
}




BENCHMARKS

- With DMD v2.079.0, Windows:

$ rdmd -O -inline -release main.d

With cfloat: 1 sec, 187 ms, 225 ╬╝s, and 5 hnsecs
With cdouble: 1 sec, 315 ms, 385 ╬╝s, and 7 hnsecs
With Complex!float: 2 secs, 451 ms, 319 ╬╝s, and 2 hnsecs  (!)
With Complex!double: 11 secs, 539 ms, and 96 ╬╝s  (!!!)

$ rdmd -O -inline -release main.d -m64

With cfloat: 1 sec, 196 ms, 312 ╬╝s, and 7 hnsecs
With cdouble: 1 sec, 295 ms, 927 ╬╝s, and 9 hnsecs
With Complex!float: 2 secs, 505 ms, 536 ╬╝s, and 4 hnsecs (!)
With Complex!double: 11 secs, 590 ms, 574 ╬╝s, and 4 hnsecs (!!!)

- With LDC 1.8.0 32-bit:

$ ldc2.exe -O3 -release -enable-inlining main.d

With cfloat: 564 ms, 669 us, and 9 hnsecs
With cdouble: 535 ms, 570 us, and 2 hnsecs
With Complex!float: 563 ms, 809 us, and 4 hnsecs
With Complex!double: 537 ms, 289 us, and 6 hnsecs

- With LDC 1.8.0 64-bit:

$ ldc2.exe -O3 -release 

[Issue 17758] assignment of different vector types should require cast

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17758

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
The specification states the following about the implicit conversion between
vectors

> Vector types of the same size can be implicitly converted among each other.

--

[Issue 17988] [ICE] Segfault when using member in map

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17988

bitter.ta...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bitter.ta...@gmx.com
 Resolution|--- |FIXED

--- Comment #1 from bitter.ta...@gmx.com ---
Works in master w/ the following output:

---
/tmp/foo.d(5): Error: only one index allowed to index int
./generated/linux/release/64/../../../../../phobos/std/algorithm/iteration.d(497):
   instantiated from here: MapResult!(__lambda2, int[])
/tmp/foo.d(5):instantiated from here: map!(int[])
./generated/linux/release/64/../../../../../phobos/std/algorithm/iteration.d(602):
   instantiated from here: __lambda2!(int[])
./generated/linux/release/64/../../../../../phobos/std/algorithm/iteration.d(497):
   instantiated from here: MapResult!(__lambda2, int[][])
/tmp/foo.d(5):instantiated from here: map!(int[][])
---

--

[Issue 18025] ICE with __traits(compiles)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18025

bitter.ta...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bitter.ta...@gmx.com
 Resolution|--- |FIXED

--- Comment #1 from bitter.ta...@gmx.com ---
Works in master, closing this.

--

[Issue 17759] struct that attempts to implicitly cast away const causes segfault

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17759

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #2 from bitter.ta...@gmx.com ---
This happens because the built-in `opEquals' that's synthesized by the compiler
contains a condition such as `(p == q)` that's recursively expanded into
`(p.foo == q) and `(p.foo.foo == q)`.
The problem lies in `resolvePropertiesX' that keeps assembling this crazy chain
where the `p' is substituted every step.

--

[Issue 18199] Error with lambda in struct initializer

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18199

--- Comment #6 from John Belmonte  ---
Here is my understanding of the current code's intention.  When presented with
"MyType foo = { ... }", the parser must infer whether the RHS is a struct
initializer or a 0-parameter function literal without knowing anything about
MyType.  A contrived example of the two cases, respectively:


  // RHS is struct initializer (e.g. MyType is struct with a string field)
  static MyType foo = {
"a" + "b",
  };

  // RHS is function literal (e.g. MyType is alias of void function())
  static MyType bar = {
"a" + "b";
  };

So the implementation uses the presence of semicolon or return tokens to infer
that the RHS is a function literal.  However that solution yields the wrong
answer when a struct initializer happens to hold certain forms of function
literals.

To fix this the parser may require an isFunctionLiteral() at least handling the
"{ ... }" form.  A caveat with this approach is that a malformed function
literal will be parsed as a struct initializer, yielding confusing error
reports.

--

[Issue 18620] `error cannot be interpreted at compile time` is missing context where error occurs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18620

--- Comment #1 from RazvanN  ---
PR: https://github.com/dlang/dmd/pull/8049

--

[Issue 18199] Error with lambda in struct initializer

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18199

--- Comment #5 from John Belmonte  ---
To clarify, the struct initializer test aborts on any semicolon or return
token, which can happen in any function literal with curly brackets.

I believe these are all the cases which need to additionally be tolerated:

  function (parameters) { statements... }
  delegate (parameters) { statements... }
  (parameters) { statements... }
  { statements... }

--

[Issue 18199] Error with lambda in struct initializer

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18199

--- Comment #4 from John Belmonte  ---
The problem stems from the presence of the "return" token in the lambda
expression, not the curly brackets.

parseInitializer() scans ahead to see if there is a struct initializer (in
curly brackets).  However the scan is aborted when the return token is hit.

https://github.com/dlang/dmd/blob/4244b8b1abea8ad26941c33464780a13f554b0bf/src/dmd/parse.d#L6043

--

[Issue 15624] opApply with @safe and @system variants can't be used with foreach syntax

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15624

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--