[Issue 4867] [GSoC] Postblit is not usable with const objects

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=4867

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #4 from RazvanN  ---
We have copy constructor now so this is not going to get fix.

--


[Issue 20365] Copy constructor not invoked on static arrays of structs but the postblit works

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20365

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #3 from RazvanN  ---
This can be nicely solved with the new hasCopyConstructor/hasPostblit traits
[1]. I will look into it.

[1] https://github.com/dlang/dmd/pull/10528

--


[Issue 20358] External initialization of private struct fields should be disallowed

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20358

--- Comment #5 from Max Samukha  ---
I disagree. Implicit constructors should not magically give public assess to
private members. That breaks encapsulation. I bet you wouldn't like it if the
compiler implicitly generated public setters for private fields. Mutating
private fields with an external initializer is analogous to that.

--


[Issue 18750] [Tracker] everything wrong with code generation for bt instruction

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18750

ag0aep6g  changed:

   What|Removed |Added

 Depends on||20363


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=20363
[Issue 20363] optimization with union, >> and ulong leads to wrong result
--


[Issue 20363] optimization with union, >> and ulong leads to wrong result

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20363

ag0aep6g  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ag0ae...@gmail.com
 Blocks||18750

--- Comment #1 from ag0aep6g  ---
Seems to be (yet another) bug related to the `bt` instruction.

Smaller test case:


ulong test(double d)
{
ulong u = * cast(ulong*) 
return (u >> 1) & 1;
}
void main()
{
ulong u = 0b10;
if (test(* cast(double*) ) == 0) assert(false); /* fails with -O */
}


The generated code for `test`:


   0:   48 0f ba e0 01  bt rax,0x1
   5:   19 c0   sbbeax,eax
   7:   f7 d8   negeax
   9:   c3  ret


It misses code that fills `rax`.


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18750
[Issue 18750] [Tracker] everything wrong with code generation for bt
instruction
--


[Issue 20365] Copy constructor not invoked on static arrays of structs but the postblit works

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20365

Suleyman Sahmi (سليمان السهمي)  changed:

   What|Removed |Added

 CC||sahmi.soulaim...@gmail.com

--


[Issue 20365] Copy constructor not invoked on static arrays of structs but the postblit works

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20365

--- Comment #2 from Suleyman Sahmi (سليمان السهمي)  
---
There is a whole jungle of pustblit calls in druntime that do not call the copy
constructor yet. Just grep the word "postblit" in druntime source to get an
idea. I contacted Razvan about it.

--


[Issue 20365] Copy constructor not invoked on static arrays of structs but the postblit works

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20365

kinke  changed:

   What|Removed |Added

 CC||ki...@gmx.net

--- Comment #1 from kinke  ---
Let's include CatAssign as well for completeness:

S[] c;
c ~= a; // no copy ctor calls, but 4 postblits

--


[Issue 20365] New: Copy constructor not invoked on static arrays of structs but the postblit works

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20365

  Issue ID: 20365
   Summary: Copy constructor not invoked on static arrays of
structs but the postblit works
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: sahmi.soulaim...@gmail.com

Copy constructor case: https://run.dlang.io/is/xzVWOi

```
extern(C) void puts(const char*);

struct S
{
long[3] a;
this(ref typeof(this)) { puts("CC"); }
}

void main()
{
S[4] a;
auto b = a;
}
```

Prints nothing. Expected to print "CC" four times.

Postblit case: https://run.dlang.io/is/OX4O8I

```
extern(C) void puts(const char*);

struct S
{
long[3] a;
this(this) { puts("PB"); }
}

void main()
{
S[4] a;
auto b = a;
}
```

prints "PB" four times as expected.

--


[Issue 20363] optimization with union, >> and ulong leads to wrong result

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20363

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--


[Issue 20362] dmd fails to infer scope parameter for delegate

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20362

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--


[Issue 20114] -checkaction=context evaluates operand second time on assertion failure

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20114

--- Comment #2 from Dlang Bot  ---
dlang/dmd pull request #10512 "Issue 20114 - -checkaction=context evaluates
operand second time on a…" was merged into master:

- 0ae5f75fce4b8a24341e0b4317f01aedd740aa6e by MoonlightSentinel:
  Issue 20114 - -checkaction=context evaluates operand second time on assertion
failure

https://github.com/dlang/dmd/pull/10512

--


[Issue 20114] -checkaction=context evaluates operand second time on assertion failure

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20114

ZombineDev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||petar.p.ki...@gmail.com
 Resolution|--- |FIXED

--


[Issue 20364] New: [REG2.069] changing length for array of typeof(null) elements kills program

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20364

  Issue ID: 20364
   Summary: [REG2.069] changing length for array of typeof(null)
elements kills program
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: sahmi.soulaim...@gmail.com

Test case:

```
void main()
{
typeof(null)[] result;
result.length = 1;
}
```

--


[Issue 20363] New: optimization with union, >> and ulong leads to wrong result

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20363

  Issue ID: 20363
   Summary: optimization with union, >> and ulong leads to wrong
result
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@d-ecke.de

auto test(double val)
{
union A
{
double a;
ulong b;
}

A fb;
fb.a = val;

auto sgn = ((fb.b >> 63) & 1) ? "-" : "+";

import std.stdio;
writeln(sgn);
}

void main()
{
test(-double.nan);
}

When running this with "rdmd -O" I get "+" not the expected "-". Without the -O
flag it works.

--


[Issue 20359] core.atomic.cas throws with null as `ifThis`

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20359

John Hall  changed:

   What|Removed |Added

 CC||john.michael.h...@gmail.com

--- Comment #1 from John Hall  ---
Writing
cas(cast(shared), null, cast(shared)b);
also causes an error.

--


[Issue 20358] External initialization of private struct fields should be disallowed

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20358

Basile-z  changed:

   What|Removed |Added

   Hardware|x86_64  |All

--


[Issue 20358] External initialization of private struct fields should be disallowed

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20358

Basile-z  changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #4 from Basile-z  ---
I vote for closing as invalid. 

Default constructors should be seen as real constructors so the private fields
are not written directly but rather copied from the constructor parameters to
the fields (conceptually). Finally explicit constructors can be used in a way
that prevents initialization of private fields, if required.

--


[Issue 20362] New: dmd fails to infer scope parameter for delegate

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20362

  Issue ID: 20362
   Summary: dmd fails to infer scope parameter for delegate
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: atila.ne...@gmail.com

With dmd 2.089.0, *without* using -preview=dip1000, this fails to compile:


void stringify(scope void delegate(scope const char[]) sink) {
sink("oops");
}

void main() {
string str;
stringify((chars) {str ~= chars; });
}


bug.d(7): Error: function bug.stringify(scope void delegate(scope
const(char[])) sink) is not callable using argument types (void)
bug.d(7):cannot pass argument __lambda1 of type void to parameter scope
void delegate(scope const(char[])) sink


It compiles successfully with -preview=dip1000. A workaround is to explicitly
add `scope` to the `chars` parameter of the delegate, and then it compiles with
and without -preview=dip1000.

This is blocking this PR:

https://github.com/dlang/dmd/pull/10506

--


[Issue 20361] New: denormalized floatingpoint number literals do not work

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20361

  Issue ID: 20361
   Summary: denormalized floatingpoint number literals do not work
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@d-ecke.de

void main()
{
float f = 1e-40f;
}

Compiling with dmd produces:

test.d(3): Error: number 1e-40f is not representable

But it is representable. The bit pattern is:

0  001000101101110

--


[Issue 3858] mixin attribute is ignored

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3858

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #3 from RazvanN  ---
Maybe a solution would be to parse string mixins at parse time and simply glue
the resulting AST to the main AST.

--


[Issue 3852] Default struct constructors needed

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3852

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #2 from RazvanN  ---
How come disbling the default constructor via `disable this();` does not solve
your issues?

I am tempted to close this as WONTFIX as the board is probably going to be
against adding the possibility of defining default constructors.

--


[Issue 3825] (D1 only) AAs entries are default initialized before the new value is evaluated

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3825

RazvanN  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #10 from RazvanN  ---
D1 is no longer supported, so I am closing this.

--


[Issue 3818] Generic error message for wrong foreach

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3818

RazvanN  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||razvan.nitu1...@gmail.com

--


[Issue 3790] [OOP] Forwarding constructors to super class

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3790

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |INVALID

--- Comment #5 from RazvanN  ---
Closing on the basis of Dmitry's proposed solution.

--


[Issue 3773] Incorrectly returning an enum error, points to enum line iso error line

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3773

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from RazvanN  ---
I cannot reproduce this in git master. I get error for trying to return
something from void functions, which is the correct behavior.

--


[Issue 3771] warn or disallow method as property usage without @property attribute

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3771

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |INVALID

--


[Issue 20360] std.variant doesn't do postblit/dtor correctly for large structs

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20360

--- Comment #1 from John Colvin  ---
related to https://issues.dlang.org/show_bug.cgi?id=12944

--


[Issue 20360] std.variant doesn't do postblit/dtor correctly for large structs

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20360

John Colvin  changed:

   What|Removed |Added

   Keywords||industry

--


[Issue 20360] New: std.variant doesn't do postblit/dtor correctly for large structs

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20360

  Issue ID: 20360
   Summary: std.variant doesn't do postblit/dtor correctly for
large structs
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

unittest
{
import std.variant;
static struct S
{
int* p;
ubyte[100] u;

this(int a)
{
p = new int(a);
}

this(this)
{
p = new int(*p);
}

~this()
{
p = null;
}
}
Variant v = S(4);
assert(v.peek!S.p !is null); // fails
}

--


[Issue 11038] static has no effect as a block attribute for imports

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=11038

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Dlang Bot  ---
@RazvanN7 created dlang/dmd pull request #10541 "Fix Issue 11038 - static has
no effect as a block attribute for imports" fixing this issue:

- Fix Issue 11038 - static has no effect as a block attribute for imports

https://github.com/dlang/dmd/pull/10541

--


[Issue 20356] exceeding template expansion limits

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20356

Dlang Bot  changed:

   What|Removed |Added

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

--- Comment #3 from Dlang Bot  ---
dlang/dmd pull request #10538 "Fix #20356 raises recursive expansion limit" was
merged into stable:

- b4a814c02a2bfdf048440ac70a6e93fff596110f by Robert Schadek:
  Fix Issue 20356 raises recursive expansion limit

  * Raises the limit from 300 to 500 and gives clearer error msg.
  * make the test give the right error msg
  * moved the constant to globals.Global
  * changed some more constants
  * rename

https://github.com/dlang/dmd/pull/10538

--


[Issue 20358] External initialization of private struct fields should be disallowed

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20358

--- Comment #3 from Max Samukha  ---
(In reply to Simen Kjaeraas from comment #2)

> The solution here would be to define the default constructor as private when
> a struct has private members. 

That would be better, but simply making the default constructor private would
outlaw other valid use cases:

struct S {
   int x;
   private int y;
   int z;
}

// partial initialization should still be allowed
S s = {1};
S s2 = {1, z: 2}; // etc

In other words, private should be the respective parameters of the default
constructor.

--


[Issue 20358] External initialization of private struct fields should be disallowed

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20358

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #2 from Simen Kjaeraas  ---
Supporting Max's argument: test.d's author should have no knowledge of S's
private fields and their allowed values. A change in S's internals would lead
to breakage in unrelated modules.

The solution here would be to define the default constructor as private when a
struct has private members. Inside s.d this would allow the exact same usage as
now, while not giving other modules access to internals that arguably shouldn't
be available to them. Constructors would need to be defined explicitly to
initialize private fields when called from other modules.

I started out agreeing with RazvanN on this, but I think the above is the best
solution.

--


[Issue 20357] format should obey space flag when printing nan or inf

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20357

Dlang Bot  changed:

   What|Removed |Added

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

--- Comment #2 from Dlang Bot  ---
dlang/phobos pull request #7263 "Fix Issue 20357 - format should obey space
flag when printing nan or inf" was merged into master:

- ea3d45e4c97954109c4aac6f52aaa7a9de95afdf by Bernhard Seckinger:
  Fix Issue 20357 - format should obey space flag when printing nan or inf

https://github.com/dlang/phobos/pull/7263

--


[Issue 20358] External initialization of private struct fields should be disallowed

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20358

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #1 from RazvanN  ---
This issue is invalid. Default constructor is allowed to initialize private
fields, otherwise you would end up with partially initialized objects. If this
behavior does not suit you, you can disable the default constructor.

I suggest closing this as invalid.

--


[Issue 20356] exceeding template expansion limits

2019-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20356

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Dlang Bot  ---
@burner updated dlang/dmd pull request #10538 "Fix #20356 raises recursive
expansion limit" fixing this issue:

- Fix Issue 20356 raises recursive expansion limit

  * Raises the limit from 300 to 500 and gives clearer error msg.
  * make the test give the right error msg
  * moved the constant to globals.Global

https://github.com/dlang/dmd/pull/10538

--