[Issue 18737] An assert(0) should be a leaf in constructor flow analysis

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

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

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8144

--

[Issue 18736] constructor calls allowed after case labels

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

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

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8143

--

[Issue 18737] New: An assert(0) should be a leaf in constructor flow analysis

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

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

  Issue ID: 18737
   Summary: An assert(0) should be a leaf in constructor flow
analysis
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

The following fails to compile, but should pass:

struct S
{
this(char);

this(int j)
{
this('a');
assert(0);
this('b');  // error: multiple constructor calls
}
}

--

[Issue 18667] Segfault in std.file.dirEntries

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
   Severity|normal  |major

--- Comment #2 from Walter Bright  ---
Raising importance to major because of its disruption to the auto testing.

--

[Issue 18736] constructor calls allowed after case labels

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--

[Issue 18688] Constructors shouldn't have implicit super call if it throws

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

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

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18736

--

[Issue 18736] New: constructor calls allowed after case labels

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

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

  Issue ID: 18736
   Summary: constructor calls allowed after case labels
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

Delegating constructor calls are not allowed after labels, but case labels and
default labels should also count as labels.

  class A
  {
this(char c) { }

this(int i)
{
switch (i)
{
case 1:  break;
default: break;
}
this('c'); // should give error
}
  }

--

[Issue 18736] constructor calls allowed after case labels

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

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

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18688

--

[Issue 17819] static foreach segfaults on __traits(allMembers)

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

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

--- Comment #5 from Seb  ---
https://issues.dlang.org/show_bug.cgi?id=18718 is very related.

--

[Issue 18718] ICE in dmd/traits.d:417

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

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

--- Comment #2 from Seb  ---
https://issues.dlang.org/show_bug.cgi?id=17819 is very related.

--

[Issue 18735] New: all versions of find and canfind should identify usage of predicate

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

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

  Issue ID: 18735
   Summary: all versions of find and canfind should identify usage
of predicate
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: ddoc
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

In the first overload of find, it says:

Elements of haystack are compared with needle by using predicate pred with
pred(haystack.front, needle)

This same description should be repeated in all flavors. It can be important
when giving a custom predicate where the two parameters are not the same type.

--

[Issue 18719] Doubly-called constructor against member when using forwarding constructors

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||safe
 CC||bugzi...@digitalmars.com
   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|enhancement |normal

--

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

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

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

--- Comment #37 from Walter Bright  ---
(In reply to timon.gehr from comment #36)
> (In reply to Walter Bright from comment #35)
> As I said, just do it if the delegate does not escape.

Yes, I thought this was clear. This only applies if the delegate escapes.

> > 2. Doing a heap alloc/free for every loop iteration is expensive, and since
> > the cost is hidden it will come as a nasty surprise.
> > ...
> 
> I don't get how this is different from other implicit heap closure
> allocations. A function that does such an implicit allocation not within a
> loop in its own body might well be called in a loop and cause a performance
> bottleneck. Profile.

People have made it clear they don't particularly like hidden allocations in
innocuous looking code. Hence the genesis of the @nogc attribute. For this
particular issue, it would be hard to look at a random loop and see if
allocations are occurring - i.e. a nasty surprise if a small change suddenly
made a big hit in performance. Profiling is not the answer, as very, very few
people profile code.


> > 3. Doing a gc allocation will generate an unbounded set of allocations, also
> > coming as a nasty surprise.
> > ...
> This is true for all implicit heap allocations. They are also often
> convenient and there are already ways to flag them.

I can hear the complaints about this already :-(


> > 4. Doing my delegate rewrite will cause a "by value" which changes the
> > semantics, so that won't work.
> > ...
> That's not true.

I believe it is:

int i = 0;
auto dg = { ++i; }
dg();
print(i);  // zero or one?

By ref would make it one, with the rewrite it would be 0 because the ref would
be to a copy of i, not the original.

> The delegate rewrite is a very hacky way
> to implement it though, and probably not really the most convenient as you
> need to thread through control flow and the generated code will not be as
> good as it could be.

Things get very sticky if you've got closures from functions nested several
levels deep. It turns out to be pretty hard to get all this stuff right. Doing
the rewrite means I know it will be correct, as it leverages all that complex,
debugged, working code.


> > I suspect the pragmatic solution is to disallow the capture of loop
> > variables by reference by escaping delegates. The user then will be notified
> > of the problem, and he can construct an efficient workaround that works for
> > his application.
> 
> This fixes the memory corruption issue without much work. Deprecation might
> be necessary even if we fix this the right way in the end, so this is a good
> first step.

At least we agree on that step :-), although I am far less sanguine about
adding hidden allocations inside loops being an acceptable option.

BTW, I belatedly realized that it wasn't just about loop variables. Capturing
non-loop variables that get destructed when they go out of scope also cannot be
done.

--

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

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

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

--- Comment #36 from timon.g...@gmx.ch ---
(In reply to Walter Bright from comment #35)
> 1. alloca() won't work, because that won't survive the end of the function.
> ...

As I said, just do it if the delegate does not escape.

> 2. Doing a heap alloc/free for every loop iteration is expensive, and since
> the cost is hidden it will come as a nasty surprise.
> ...

I don't get how this is different from other implicit heap closure allocations.
A function that does such an implicit allocation not within a loop in its own
body might well be called in a loop and cause a performance bottleneck.
Profile.

> 3. Doing a gc allocation will generate an unbounded set of allocations, also
> coming as a nasty surprise.
> ...

This is true for all implicit heap allocations. They are also often convenient
and there are already ways to flag them.

> 4. Doing my delegate rewrite will cause a "by value" which changes the
> semantics, so that won't work.
> ...

That's not true. It just gets rid of the memory corruption. The capture is
still by reference, which you can easily verify by creating more than one
closure over the same instance of the variable. This is the standard semantics
for this kind of thing. The delegate rewrite is a very hacky way to implement
it though, and probably not really the most convenient as you need to thread
through control flow and the generated code will not be as good as it could be.

> I suspect the pragmatic solution is to disallow the capture of loop
> variables by reference by escaping delegates. The user then will be notified
> of the problem, and he can construct an efficient workaround that works for
> his application.

This fixes the memory corruption issue without much work. Deprecation might be
necessary even if we fix this the right way in the end, so this is a good first
step.

--

[Issue 15615] Creating a Variant with a const primitive type doesn't compile

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

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

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 18730] dmd miscompiles core.bitop.bt with -O

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

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

--- Comment #6 from Ketmar Dark  ---
tnank you.

--

[Issue 18734] bitnum parameter of core.bitop.bt should be signed

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

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

Ketmar Dark  changed:

   What|Removed |Added

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

--

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

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

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

--- Comment #35 from Walter Bright  ---
1. alloca() won't work, because that won't survive the end of the function.

2. Doing a heap alloc/free for every loop iteration is expensive, and since the
cost is hidden it will come as a nasty surprise.

3. Doing a gc allocation will generate an unbounded set of allocations, also
coming as a nasty surprise.

4. Doing my delegate rewrite will cause a "by value" which changes the
semantics, so that won't work.

I suspect the pragmatic solution is to disallow the capture of loop variables
by reference by escaping delegates. The user then will be notified of the
problem, and he can construct an efficient workaround that works for his
application.

--

[Issue 18730] dmd miscompiles core.bitop.bt with -O

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

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

--- Comment #5 from ag0aep6g  ---
(In reply to ag0aep6g from comment #3)
> 2) File a new issue for the larger problem: core.bitop.bt's bitnum parameter
> is a size_t when it should be a ptrdiff_t. Then bt's body has to be adjusted
> for that, because D doesn't have negatives indices. And dmd has to be
> adjusted to recognize the new body.

Filed that as issue 18734.

--

[Issue 18734] New: bitnum parameter of core.bitop.bt should be signed

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

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

  Issue ID: 18734
   Summary: bitnum parameter of core.bitop.bt should be signed
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Keywords: wrong-code
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Closely related to issue 18730. But 18730 is x86-64 only, while this one
affects both x86 and x86-64.

The issue is best demonstrated with 32-bit code:


import std.stdio;
void main()
{
static assert(size_t.sizeof == 4); /* We're in 32-bit code. */

enum len = 2 ^^ 27;
assert(len * size_t.sizeof * 8L == 2L ^^ 32);
/* Exactly enough space for size_t.max bits. */

auto a = new size_t[len + 1];
/* Adding one because we're going to start from a[1]. */

a[$ - 1] = 0x8000_; /* Set the very last bit. */
writeln(bt([1], size_t.max)); /* Try to read it. */
/* Without -O: 1, correct. With -O: 0, wrong. */

a[$ - 1] = 0; /* Unset the very last bit. */
a[0] = 0x8000_; /* Set the last bit of the first size_t. */
writeln(bt([1], size_t.max)); /* Try reading the very last bit again. */
/* Without -O: "0", correct. With -O: "1", wrong. */
}

/* Copied from core.bitop. */
int bt(in size_t* p, size_t bitnum) pure @system
{
static if (size_t.sizeof == 8)
return ((p[bitnum >> 6] & (1L << (bitnum & 63 != 0;
else static if (size_t.sizeof == 4)
return ((p[bitnum >> 5] & (1  << (bitnum & 31 != 0;
else
static assert(0);
}


The wrong behavior happens because core.bitop.bt is optimized using the bt
instruction. And the bt instruction interprets offset (bitnum) as signed. So
instead of going size_t.max bits up from `a[1]`, it goes 1 bit down.

If core.bitop.bt is supposed to directly map to the bt instruction, the type of
the bitnum parameter should be ptrdiff_t, not size_t. Making that change
probably means that the body of core.bitop.bt has to be changed to accommodate
for negative values of bitnum. And then DMD will have to be updated to
recognize the new body.

x86-64 is affected in the same way, but you can't actually have an array of
2^63 bits, so it can't be hit like on x86.

--

[Issue 18730] dmd miscompiles core.bitop.bt with -O

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

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

ag0aep6g  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18734

--

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

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

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

--- Comment #34 from timon.g...@gmx.ch ---
(In reply to timon.gehr from comment #33)
> ...
> In D, if the compiler can prove that closures don't escape, alloca might be
> an option.

(Or simply malloc/free, of course.)

--

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

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

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

--- Comment #33 from timon.g...@gmx.ch ---
(In reply to Walter Bright from comment #32)
> > Other programming languages, even those that always capture by reference, 
> > do not have this problem.
> 
> So, for a variable declared in a loop, where do they allocate storage for it?

For some, this is an implementation detail, others explicitly specify heap
allocation.

In D, if the compiler can prove that closures don't escape, alloca might be an
option.

--

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

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

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

--- Comment #32 from Walter Bright  ---
> Other programming languages, even those that always capture by reference, do 
> not have this problem.

So, for a variable declared in a loop, where do they allocate storage for it?

--

[Issue 18615] Rebindable!A doesn't use class A's opEquals (returns a is b instead)

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

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

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

https://github.com/dlang/phobos/commit/65b1f1af77b099ab97c94d802f027fa89cef0165
Fix Issue 18615 - Rebindable!A calls A.opEquals

The issue was that Rebindable!A always compared two rebindable
references by 'a is b', not by A.opEquals. With this fix, two rebindable
references, or a rebindable and a raw reference, always compare with
A.opEquals.

https://github.com/dlang/phobos/commit/9de28234bff85df508890f3b202515b63e590319
Merge pull request #6370 from SimonN/issue18615

Fix Issue 18615 - Rebindable!A calls A.opEquals
merged-on-behalf-of: Jack Stouffer 

--

[Issue 18615] Rebindable!A doesn't use class A's opEquals (returns a is b instead)

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

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

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

   What|Removed |Added

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

--

[Issue 18730] dmd miscompiles core.bitop.bt with -O

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

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

--- Comment #4 from Ketmar Dark  ---
yeah. would you do it, please?

--

[Issue 18730] dmd miscompiles core.bitop.bt with -O

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

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

--- Comment #3 from ag0aep6g  ---
(In reply to Ketmar Dark from comment #1)
> it segfaults on x86 too. but i won't change "hardware" field, 'cause it
> seems that with x86_64 there is a codegen bug too, and fixing segfault for
> x86_64 should automatically fix it for x86.

I think we can split this in two:

1) Fix the x86-64 issue presented here by fixing the register size. This is the
easy part. It doesn't fix the situation on x86.

2) File a new issue for the larger problem: core.bitop.bt's bitnum parameter is
a size_t when it should be a ptrdiff_t. Then bt's body has to be adjusted for
that, because D doesn't have negatives indices. And dmd has to be adjusted to
recognize the new body.

--

[Issue 15768] std.stdio.File does not support __gshared semantics of stdout/err/in

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com
Summary|std.stdio.trustedStdout |std.stdio.File does not
   |accesses __gshared data |support __gshared semantics
   |without synchronization.|of stdout/err/in

--

[Issue 18730] dmd miscompiles core.bitop.bt with -O

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

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

ag0aep6g  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from ag0aep6g  ---
https://github.com/dlang/dmd/pull/8142

--

[Issue 18733] std.math.remquo's behavior with infinity is platform dependent

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

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

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

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

--- Comment #31 from timon.g...@gmx.ch ---
(timon.gehr meant to write in comment #30)
> (In reply to Walter Bright from comment #28)
> > Added the `safe` keyword because of the immutable variable issue described
> > in the comments.
> 
> This is not a one-off issue. It is a symptom of the generally wrong
> behavior. DMD is sharing the same memory for different variables with
> *overlapping* lifetimes. This is plain memory corruption, whether or not
> immutable is involved.

--

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

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

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

--- Comment #30 from timon.g...@gmx.ch ---
(In reply to Walter Bright from comment #28)
> Added the `safe` keyword because of the immutable variable issue described
> in the comments.

This is not a one-off issue. It is a symptom of the generally wrong behavior.
DMD is sharing the same memory for different variables with non-overlapping
lifetimes. This is plain memory corruption, whether or not immutable is
involved.

--

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

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

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

--- Comment #29 from timon.g...@gmx.ch ---
(In reply to Walter Bright from comment #27)
> D closures are "by reference" rather than "by value". I make use of it being
> by reference all the time, as well as it being much more efficient. Changing
> it would likely break all sorts of code. So then the question is, what to do
> if you want it by value?
> ...

No, this is not about this distinction. Other programming languages, even those
that always capture by reference, do not have this problem. This form of memory
corruption cannot reasonably be defined away as a language feature.

> Now, the compiler could actually rewrite the delegate into the nested form
> above, but as I said, this changes the semantics of existing code, as well as
> being pretty inefficient. I doubt it would be acceptable.

All bug fixes change behavior of existing code. The current behavior is
unacceptable.

--

[Issue 18717] Segfault in BitManip

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

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

--- Comment #3 from Cédric Picard  ---
Thanks a lot, your interpretation makes sense.

--

[Issue 18732] Can use template as type in a templatized class

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

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

Ketmar Dark  changed:

   What|Removed |Added

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

--

[Issue 18730] dmd miscompiles core.bitop.bt with -O

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

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

Ketmar Dark  changed:

   What|Removed |Added

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

--- Comment #1 from Ketmar Dark  ---
it segfaults on x86 too. but i won't change "hardware" field, 'cause it seems
that with x86_64 there is a codegen bug too, and fixing segfault for x86_64
should automatically fix it for x86.

--

[Issue 7211] Initializing const members in derived classes' constructors

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

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #2 from RazvanN  ---
As Maksim said, the error has changed to "test.d(10): Error: cannot modify
immutable expression this.x". This  is the correct behavior since x is
constructed in the implicit super call to C. When D's constructor tries to
modify it, it is already cooked and cannot be modified. Closing as fixed.

--

[Issue 18704] std/datetime/stopwatch.d(452) assertion failure on auto-tester

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

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

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

https://github.com/dlang/phobos/commit/6f1bb469ef4732c500cf98d096ff05918642
Fix Issue 18704 - std/datetime/stopwatch.d(452) assertion failure on
auto-tester

https://github.com/dlang/phobos/commit/74e6dab44350f80aeb85501c6074119166bb5194
Merge pull request #6404 from wilzbach/fix-18704

Fix Issue 18704 - std/datetime/stopwatch.d(452) assertion failure on
auto-tester
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 18704] std/datetime/stopwatch.d(452) assertion failure on auto-tester

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

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

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

   What|Removed |Added

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

--

[Issue 13495] DMD fails to call struct constructor with default args when default constructor is @disabled

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

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #2 from RazvanN  ---
The code in the OP now issues a deprecation : Deprecation: constructor
`test.S.this` all parameters have default arguments, but structs cannot have
default constructors. PR : https://github.com/dlang/dmd/pull/5331

Default construction is disabled, so this case is no longer actual. Closing as
fixed.

--

[Issue 18733] New: std.math.remquo's behavior with infinity is platform dependent

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

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

  Issue ID: 18733
   Summary: std.math.remquo's behavior with infinity is platform
dependent
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

version(X86_64)
assert(remquo(1.0, real.infinity, n) == 1.0);
else
assert(remquo(1.0, real.infinity, n) is -real.nan);

D should not have these inconsistencies, and should unify the behavior of C
libraries into a logical whole.

--

[Issue 18228] this(this a){} doesn't generate postblit ctor; this(this){} does

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

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #3 from RazvanN  ---
PR : https://github.com/dlang/dmd/pull/8141

--

[Issue 18594] X is not an lvalue should have a better error message

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

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

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

https://github.com/dlang/dmd/commit/ea309c0967e473db3c19e202ffcaf563d9cfff63
Issue 12663, 18594 - Replace lvalue in error messages with 'cannot modify'

https://github.com/dlang/dmd/commit/4574f6891b925c768382ae6dba57b93c4b66bf13
Merge pull request #8009 from wilzbach/fix-18594

Issue 18594 - Replace lvalue in error messages with 'cannot modify'
merged-on-behalf-of: Mike Franklin 

--

[Issue 12663] Wrong error message for mutation of immutable static array

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

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

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

https://github.com/dlang/dmd/commit/ea309c0967e473db3c19e202ffcaf563d9cfff63
Issue 12663, 18594 - Replace lvalue in error messages with 'cannot modify'

--

[Issue 18732] New: Can use template as type in a templatized class

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

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

  Issue ID: 18732
   Summary: Can use template as type in a templatized class
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

---
class Foo(bool b)
{
// can use Foo without template param
static assert(__traits(compiles, new Foo));  // 1
// because
static assert(is(Foo == Foo!false));
}

void main()
{
Foo!false foo;
}
---

The Q is: is line before comment 1 accepted on purpose ?

--

[Issue 18130] ICE on zero-length `out` array parameter

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

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

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

https://github.com/dlang/dmd/commit/5abef224cbd6c580239e2cf401bb74044bb4bb3e
Fix Issue 18130 - ICE on zero-length `out` array parameter

https://github.com/dlang/dmd/commit/6957a6a622d05cd0251428b2d948b219db2d8665
Merge pull request #8127 from wilzbach/fix-18130

Fix Issue 18130 - ICE on zero-length `out` array parameter
merged-on-behalf-of: Jacob Carlborg 

--

[Issue 18130] ICE on zero-length `out` array parameter

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

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

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

   What|Removed |Added

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

--

[Issue 18696] runnable/test18322.d is failing spuriously on Win32

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

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

Seb  changed:

   What|Removed |Added

   Hardware|x86 |x86_64
   Severity|enhancement |normal

--

[Issue 17982] Support for const(Class) in algorithm.searching.extremum

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

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

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

   What|Removed |Added

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

--

[Issue 17982] Support for const(Class) in algorithm.searching.extremum

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

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

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

https://github.com/dlang/phobos/commit/64d3a078d3df789734af2644d1f3c51590f3e6e7
Fix Issue 17982 - Support for const(Class) in algorithm.searching.extremum

https://github.com/dlang/phobos/commit/193c61d985a9645014b2161b59ddb8692308e063
Merge pull request #6157 from wilzbach/fix-17982

Fix Issue 17982 - Support for const(Class) in algorithm.searching.extremum
merged-on-behalf-of: Nathan Sashihara 

--

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||safe

--- Comment #28 from Walter Bright  ---
Added the `safe` keyword because of the immutable variable issue described in
the comments.

--

[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.

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

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

--- Comment #27 from Walter Bright  ---
D closures are "by reference" rather than "by value". I make use of it being by
reference all the time, as well as it being much more efficient. Changing it
would likely break all sorts of code. So then the question is, what to do if
you want it by value?

One solution to creating such a delegate is to create it inside a nested
function:

  import core.stdc.stdio;
  int main()
  {
foreach (i; 0 .. 2)
{
void delegate(int) nested()
{
auto myi = i; // capture current value of i for use by del()
void del(int x)  // the real delegate
{
printf(" = %p\n", );
}
return 
}
auto dg = nested();
dg(1);
}
return 0;
  }

Running it:
   = 00261014
   = 00261024

This works because `del` escapes its scope, and so the compiler allocates a
closure each time nested() is called, and `myi` is captured in that closure.

Now, the compiler could actually rewrite the delegate into the nested form
above, but as I said, this changes the semantics of existing code, as well as
being pretty inefficient. I doubt it would be acceptable.

--