[Issue 14193] Provide a way to mangle a D struct as a C++ class.

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |WORKSFORME

--- Comment #5 from Walter Bright  ---
  extern (C++, class) struct ...

will mangle it as a class.

--

[Issue 15503] Namespace lookup not following scoping rules

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

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #2 from Walter Bright  ---
(In reply to Walter Bright from comment #1)
> https://github.com/D-Programming-Language/dmd/pull/5330

And it was pulled!

--

[Issue 15611] DMD doesn't build with VS2015

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

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #3 from Walter Bright  ---
(In reply to Manu from comment #2)
> https://github.com/D-Programming-Language/dmd/pull/5367
> 
> This fixes the compile error.

And it was pulled!

--

[Issue 17359] C++ Interfacing: function with 'static' array parameter cannot be linked (x64)

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

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

--- Comment #4 from Walter Bright  ---
To get the same results in C++ and D:

C++:
  void cppFunc(float ()[3]) { }

D:
  extern(C++) void cppFunc(ref float[3] color) { }

Both mangle to:
  ?cppFunc@@YAXAAY02M@Z

--

[Issue 17890] cpp_long is not declared for Posix 64bit

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

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #4 from Jonathan M Davis  ---
It's issues like that which make it so that I avoid long like the plague in
C/C++. Personally, I use int if I don't care about the size, and one of the
(u)int*_t types if I do, and I'm very glad that D mostly doesn't have the same
problem where the size of types varies from system to system (though we're kind
of stuck with regards to stuff like size_t due to how important it is that it
interact properly with the pointer size on the machine).

--

[Issue 17890] cpp_long is not declared for Posix 64bit

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

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

--- Comment #3 from Walter Bright  ---
(In reply to Илья Ярошенко from comment #0)
> ...
> BTW, why c_long is always 32 bit for windows?

Because `long` in 64 bit VC++ is 32 bits.

--

[Issue 17890] cpp_long is not declared for Posix 64bit

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/druntime/pull/2160

--

[Issue 18720] Segfault in src/gc/impl/conservative/gc.d:1990

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

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

--- Comment #1 from Seb  ---
Just to clarify a bit more about this, this is spuriously happening on CircleCi
for dlang/phobos when it runs DScanner and apparently the GC finds some invalid
memory during its marking phase.

--

[Issue 18751] chunkBy predicate cannot access local variable

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

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

--- Comment #2 from hst...@quickfur.ath.cx ---
This is related to issue #14909, but the PR only fixes this problem, not that
one, so I'm keeping the bug reports separate for now.

--

[Issue 18751] chunkBy predicate cannot access local variable

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

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

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

   What|Removed |Added

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

--

[Issue 14909] Template argument of std.algoirthm.iteration.chunkBy cannot access a local variable

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

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

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

   What|Removed |Added

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

--

[Issue 18751] chunkBy predicate cannot access local variable

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

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

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

   What|Removed |Added

   Keywords||pull

--- Comment #1 from hst...@quickfur.ath.cx ---
https://github.com/dlang/phobos/pull/6441

--

[Issue 18751] New: chunkBy predicate cannot access local variable

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

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

  Issue ID: 18751
   Summary: chunkBy predicate cannot access local variable
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Code:
---
unittest
{
import std.algorithm.comparison : equal;
import std.algorithm.iteration : chunkBy;

string[] data = [ "abc", "abc", "def" ];
int[] indices = [ 0, 1, 2 ];

auto chunks = indices.chunkBy!((i, j) => data[i] == data[j]);
assert(chunks.equal!equal([ [ 0, 1 ], [ 2 ] ]));
}
---

Compiler output:
---
/usr/src/d/phobos/std/algorithm/iteration.d(1761): Error: function
test.__unittest_L9_C1.ChunkByImpl!(__lambda1, int[]).ChunkByImpl.Group.popFront
cannot access frame of function test.__unittest_L9_C1
/usr/src/d/phobos/std/range/primitives.d(884): Error: template instance
`std.range.primitives.isInputRange!(Group)` error instantiating
/usr/src/d/phobos/std/algorithm/iteration.d(1781):instantiated from
here: isForwardRange!(Group)
---

--

[Issue 18749] bt instruction using 64-bit register for 32-bit offset

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

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

ag0aep6g  changed:

   What|Removed |Added

 Blocks||18750


Referenced Issues:

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

[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

 Blocks||18750


Referenced Issues:

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

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

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

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

  Issue ID: 18750
   Summary: [Tracker] everything wrong with code generation for bt
instruction
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com
Depends on: 18730, 18734, 18748, 18749

Code generation for the bt instruction has quite some bugs. This is a tracker
issue to have everything in one place.


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18730
[Issue 18730] dmd miscompiles core.bitop.bt with -O
https://issues.dlang.org/show_bug.cgi?id=18734
[Issue 18734] bitnum parameter of core.bitop.bt should be signed
https://issues.dlang.org/show_bug.cgi?id=18748
[Issue 18748] bt instruction with immediate offset uses 64-bit variant for
32-bit data
https://issues.dlang.org/show_bug.cgi?id=18749
[Issue 18749] bt instruction using 64-bit register for 32-bit offset
--

[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

ag0aep6g  changed:

   What|Removed |Added

 Blocks||18750


Referenced Issues:

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

[Issue 18748] bt instruction with immediate offset uses 64-bit variant for 32-bit data

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

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

ag0aep6g  changed:

   What|Removed |Added

 Blocks||18750


Referenced Issues:

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

[Issue 18749] New: bt instruction using 64-bit register for 32-bit offset

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

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

  Issue ID: 18749
   Summary: bt instruction using 64-bit register for 32-bit offset
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: wrong-code
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com


ulong f(ulong* p, uint shift)
{
return (*p >> shift) & 1;
}
ulong g(ulong* p, ulong shift)
{
return f(p, cast(uint) shift);
}
void main()
{
enum shift = uint.max + 1L;
assert(cast(uint) shift == 0);
ulong s = 1;
assert(g(, shift));
}


Compile with `-O`. Resulting program segfaults.

Generated code for f and g:


 <_D4test1fFPmkZm>:
   0:   55  push   rbp
   1:   48 8b ecmovrbp,rsp
   4:   48 0f a3 3e bt QWORD PTR [rsi],rdi
   8:   19 c0   sbbeax,eax
   a:   f7 d8   negeax
   c:   5d  poprbp
   d:   c3  ret

 <_D4test1gFPmmZm>:
   0:   55  push   rbp
   1:   48 8b ecmovrbp,rsp
   4:   e8 00 00 00 00  call   9 <_D4test1gFPmmZm+0x9>
5: R_X86_64_PLT32   _D4test1fFPmkZm-0x4
   9:   5d  poprbp
   a:   c3  ret


The bt instruction in f should use edi instead of rdi. The high bits of rdi are
garbage left over from the call to g.

The code for g is correct. It's only included to show what's going on: g
immediately calls f, without zeroing the high bits of rdi.

--

[Issue 18748] New: bt instruction with immediate offset uses 64-bit variant for 32-bit data

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

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

  Issue ID: 18748
   Summary: bt instruction with immediate offset uses 64-bit
variant for 32-bit data
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: wrong-code
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com


int bt_32_imm(in uint* p)
{
enum bitnum = 1;
return ((p[bitnum >> 5] & (1 << (bitnum & 31 != 0;
}
void main()
{
import core.sys.posix.sys.mman;
import core.sys.posix.unistd;
// Allocate two pages.
immutable sz = 2 * sysconf(_SC_PAGESIZE);
auto m = mmap(null, sz, PROT_READ, MAP_PRIVATE | MAP_ANON, -1, 0);
// Discard the higher page. It becomes unreadable.
munmap(m + sz / 2, sz / 2);
// Try looking at the last 4 bytes of the readable page.
uint* p = cast(uint*) (m + sz / 2 - uint.sizeof);
bt_32_imm(p);
munmap(m, sz / 2); // Free the readable page.
}


Compile with `-O`. Resulting program segfaults.

Generated code for bt_32_imm:


   0:   55  push   rbp
   1:   48 8b ecmovrbp,rsp
   4:   48 0f ba 27 01  bt QWORD PTR [rdi],0x1
   9:   19 c0   sbbeax,eax
   b:   f7 d8   negeax
   d:   5d  poprbp
   e:   c3  ret


The bt instruction should be the 32-bit variant (DWORD instead of QWORD). The
64-bit variant tries to load 8 bytes, but only 4 are accessible.

--

[Issue 17607] not an associative array initializer

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

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

--- Comment #5 from Andre  ---
(In reply to John Colvin from comment #3)
> My use case involves structures with these initialisers being used by people
> who aren't really D programmers, so it looks bad and is confusing to have
> the extra `( ... )` for me too.
> 
> Hopefully there is a solution. I don't think it's a case of needing improved
> syntax in the language, it's just a compiler bug.

I just have another look. The workaround is unfortunately not working but
causing a lot of errors:

struct PutItemRequest
{
AttributeValue[string] item;
}

struct AttributeValue
{
string S;
}

void main()
{
PutItemRequest request = {
item: ([
"field1": {S: "LALA"}
])
};
}

test2.d(15): Error: found } when expecting ; following statement
test2.d(16): Error: found ] instead of statement
test2.d(17): Error: found ; when expecting ,
test2.d(18): Error: expression expected, not }
test2.d(18): Error: key:value expected for associative array literal
test2.d(18): Error: found EOF when expecting ,
test2.d(14): Error: found EOF when expecting ]
test2.d(14): Error: found EOF when expecting )
test2.d(18): Error: found end of file instead of initializer
test2.d(18): Error: semicolon expected, not EOF
test2.d(18): Error: found EOF when expecting } following compound statement

--

[Issue 18747] [Structs, Unions]

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
PR https://github.com/dlang/dlang.org/pull/2337

--

[Issue 18747] New: [Structs, Unions]

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

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

  Issue ID: 18747
   Summary: [Structs, Unions]
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: trivial
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: vijay...@gmail.com

In the example for union initialisation, the variable y should be of type V
rather than type U.

--

[Issue 18746] function returning empty struct isn't called if used in equality expression

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

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

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

--

[Issue 18746] function returning empty struct isn't called if used in equality expression

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

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com
   Assignee|nob...@puremagic.com|razvan.nitu1...@gmail.com

--

[Issue 17167] dmd fails to write to file or create directory with more than 248 characters in the path

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

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

--- Comment #9 from Atila Neves  ---
Have you checked this page?

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

I filed this bug because dub was using relative paths and ended up trying to
link to
..\..\..\..\..\Users\%USERNAME%\AppData\Roaming\dub\packages\package-name-version\package-name.

Before the fix, if the dub path with several .. was too large (which happened
often), nothing would work. Now, it does.

It's possible that passing in an absolute path is different. I would still say
that it's a new bug.

--

[Issue 11331] Inefficient initialization of struct with members = void

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

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

Shachar Shemesh  changed:

   What|Removed |Added

 CC||shac...@weka.io

--

[Issue 16956] struct .init is generated even for void-initialized structs

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

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

Shachar Shemesh  changed:

   What|Removed |Added

 CC||shac...@weka.io

--

[Issue 8929] long.min is a Voldemort literal

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

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

Mitu  changed:

   What|Removed |Added

 CC||the.mail.of@gmail.com

--

[Issue 13762] -9223372036854775808L cause integer overflow error

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

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

--- Comment #2 from Simen Kjaeraas  ---


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

--

[Issue 8929] long.min is a Voldemort literal

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

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

--- Comment #8 from Simen Kjaeraas  ---
*** Issue 13762 has been marked as a duplicate of this issue. ***

--

[Issue 13762] -9223372036854775808L cause integer overflow error

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

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

Mitu  changed:

   What|Removed |Added

 CC||the.mail.of@gmail.com

--