[Issue 15315] can break immutable with std.algorithm.move

[via Digitalmars-d-bugs]

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

--- Comment #3 from Andrei Alexandrescu  ---
Indeed, apologies. The target cannot be immutable.

--

[Issue 15315] can break immutable with std.algorithm.move

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #2 from hst...@quickfur.ath.cx ---
Wait, what? Aren't *both* k1.id and k2.id *immutable*?  How could move(k2,k1)
be valid, since it would overwrite k1, which violates the immutability of
k1.id?

--

[Issue 15315] can break immutable with std.algorithm.move

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #1 from Andrei Alexandrescu  ---
This should pass regardless of safe. The move function should simply copy the
integer without overwriting it. This is because int does not have an elaborate
postblit so it is cheap to copy.

--

[Issue 17346] Inconsistent l/rvalue overload resolution

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
It does work with inout.

Perhaps the reason it doesn't work is because it might view calling Y1(x1_lval)
as Y1(cast(const)x1_lval)

which seems to be an rvalue. But clearly there is no double indirection here,
and if you remove the non-ref constructor, the const ref one is then chosen.

--

[Issue 15315] can break immutable with std.algorithm.move

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||safe

--

[Issue 17347] DMD generates different (and wrong) output in -release mode

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #1 from ag0ae...@gmail.com ---
For me, the code misbehaves even without -release. I get
"core.exception.SwitchError@test(15): No appropriate switch clause found".

As far as I can tell, this is a duplicate of issue 15538. I'm marking this as
such. Please revert if there's a difference I'm missing.

*** This issue has been marked as a duplicate of issue 15538 ***

--

[Issue 15538] wrong code with switch

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||alexander.brec...@gmail.com

--- Comment #6 from ag0ae...@gmail.com ---
*** Issue 17347 has been marked as a duplicate of this issue. ***

--

[Issue 17347] New: DMD generates different (and wrong) output in -release mode

[via Digitalmars-d-bugs]

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

  Issue ID: 17347
   Summary: DMD generates different (and wrong) output in -release
mode
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: alexander.brec...@gmail.com

The following snippet correctly prints "0" when compiled with dmd (no -release)
or ldc. However, adding -release prints a weird value. The value is slightly
different for each run, but stays in the same number region.

DMD64 D Compiler v2.074.0 (ArchLinux)

$ dmd -release app.d && ./app
140734704773424

I was not able to further reduce the code, as changing seemingly unimportant
things, like removing the "number" field from Wrapper, "fixes" the issue:

import std.stdio;

void main() {
writeln(f(Wrapper(ABCD.B, 1)).length);
}

enum ABCD { A, B, C, D }

struct Wrapper {
ABCD abcd;
uint number;
}

bool[] f(Wrapper x) {
final switch(x.abcd) {
case ABCD.A:
case ABCD.B:
case ABCD.C:
case ABCD.D:
return [];
}
}



Here's the relevant output of objdump -D, just in case it helps:

0043abc8 <_Dmain>:
  43abc8:55   push   %rbp
  43abc9:48 8b ec mov%rsp,%rbp
  43abcc:48 83 ec 10  sub$0x10,%rsp
  43abd0:c7 45 f8 01 00 00 00 movl   $0x1,-0x8(%rbp)
  43abd7:c7 45 fc 01 00 00 00 movl   $0x1,-0x4(%rbp)
  43abde:48 8b 7d f8  mov-0x8(%rbp),%rdi
  43abe2:e8 0d 00 00 00   callq  43abf4 <_D3app1fFS3app7WrapperZAb>
  43abe7:48 89 c7 mov%rax,%rdi
  43abea:e8 41 00 00 00   callq  43ac30
<_D3std5stdio14__T7writelnTmZ7writelnFNfmZv>
  43abef:31 c0xor%eax,%eax
  43abf1:c9   leaveq 
  43abf2:c3   retq   
...

0043abf4 <_D3app1fFS3app7WrapperZAb>:
  43abf4:55   push   %rbp
  43abf5:48 8b ec mov%rsp,%rbp
  43abf8:48 83 ec 10  sub$0x10,%rsp
  43abfc:48 89 7d f8  mov%rdi,-0x8(%rbp)
  43ac00:48 83 ff 03  cmp$0x3,%rdi
  43ac04:77 26ja 43ac2c
<_D3app1fFS3app7WrapperZAb+0x38>
  43ac06:48 8d 05 33 fb 02 00 lea0x2fb33(%rip),%rax# 46a740
<_IO_stdin_used+0x10>
  43ac0d:48 63 0c b8  movslq (%rax,%rdi,4),%rcx
  43ac11:48 8d 04 01  lea(%rcx,%rax,1),%rax
  43ac15:ff e0jmpq   *%rax
  43ac17:31 f6xor%esi,%esi
  43ac19:48 8d 3d 20 40 24 00 lea0x244020(%rip),%rdi#
67ec40 <_D11TypeInfo_Ab6__initZ>
  43ac20:e8 0f 22 00 00   callq  43ce34 <_d_arrayliteralTX>
  43ac25:48 89 c2 mov%rax,%rdx
  43ac28:31 c0xor%eax,%eax
  43ac2a:c9   leaveq 
  43ac2b:c3   retq   
  43ac2c:c9   leaveq 
  43ac2d:c3   retq   
...

--

[Issue 17346] New: Inconsistent l/rvalue overload resolution

[via Digitalmars-d-bugs]

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

  Issue ID: 17346
   Summary: Inconsistent l/rvalue overload resolution
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: petar.p.ki...@gmail.com

As Steven mentioned in this forum post [1], given an overload that varies
solely on ref, then rvalue arguments should go to the non-ref and lvalue
arguments should go to the ref. A simple test indicates that the above rule is
true, but only if the ref overload is non-const:

struct X { int x; }

struct Y1
{
this(X x)
{
writeln("rvalue: ", x.x);
}

this(const ref X x) // const
{
writeln("const lvalue ref: ", x.x);
}
}

struct Y2
{
this(X x)
{
writeln("rvalue: ", x.x);
}

this(ref X x) // non-const
{
writeln("lvalue ref: ", x.x);
}
}

import std.stdio;

void main()
{
auto y1_rval = Y1(X(1));
auto x1_lval = X(2);
auto y1_lval = Y1(x1_lval); // should call the ref-overload

auto y2_rval = Y2(X(3));
auto x2_lval = X(4);
auto y2_lval = Y2(x2_lval); // should call the ref-overload
}

Expected output:
Rvalue: 1
const lvalue ref: 2
Rvalue: 3
Lvalue ref: 4

Actual output:
Rvalue: 1
Rvalue: 2
Rvalue: 3
Lvalue ref: 4

[1]: http://forum.dlang.org/post/odl0e1$1qkq$1...@digitalmars.com

--

[Issue 7390] Problem in generating switch cases with a static foreach

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #4 from Nick Treleaven  ---
(In reply to bearophile_hugs from comment #0)
> switch (c) { // OK
> foreach (X; xy) {
> case X: break;
> }
> default: break;
> }

The foreach break line above should error, this seems to be the bug. Still
present with 2.074.

> switch (c) {
> case 'z': break;
> foreach (X; xy) {
> case X: break;
> }
> default: break; // Error: switch case fallthrough
> }
> }

This is correct.

--