[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/4b74c5f687a06d95c4ffe6e8aefe10f88acc098b
Remove deprecated `std.concurrency.MessageBox.isClosed() const`.

Within Phobos, this is the only occurrence of synchronizing on an immutable
object. Removal of this deprecated function allows us to resolve Issue 14251.

--

[Issue 15845] Windows console cannot read properly UTF-8 lines

[via Digitalmars-d-bugs]

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

--- Comment #1 from Steven Schveighoffer  ---
*** Issue 15846 has been marked as a duplicate of this issue. ***

--

[Issue 15846] Windows console cannot read properly UTF-8 lines

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |DUPLICATE

--- Comment #1 from Steven Schveighoffer  ---


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

--

[Issue 15846] New: Windows console cannot read properly UTF-8 lines

[via Digitalmars-d-bugs]

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

  Issue ID: 15846
   Summary: Windows console cannot read properly UTF-8 lines
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: jv_vor...@msn.com

module runnable;

import std.stdio;
import std.string : chomp;
import std.experimental.logger;

void doSomethingElse(char[] data)
{
writeln("hello!");
}

int main(string[] args)
{
/* Some fix I found in UTF-8 related problems, I'm using Windows 10 */
version(Windows)
{
import core.sys.windows.windows;
if (SetConsoleCP(65001) == 0)
throw new Exception("failure");
if (SetConsoleOutputCP(65001) == 0)
throw new Exception("failure");
}
FileLogger fl = new FileLogger("log.log");
char[] readerBuffer;

readln(readerBuffer);
readerBuffer = chomp(readerBuffer);

fl.info(readerBuffer.length); /* <- if the readed string contains at least
one UTF-8
char this gets 0, else it prints its
length
   */

if (readerBuffer != "exit")
doSomethingElse(readerBuffer);

/* Also, all the following code doesn't run as expected, the program
doesn't wait for
   you, it executes readln() even without pressing/sending a key */
readln(readerBuffer);
fl.info(readerBuffer.length);
readln(readerBuffer);
fl.info(readerBuffer.length);
readln(readerBuffer);
fl.info(readerBuffer.length);
readln(readerBuffer);
fl.info(readerBuffer.length);
readln(readerBuffer);
fl.info(readerBuffer.length);

return 0;
}

The code above doesn't work properly on windows if you input at least one of
the following chars: á, é, í, ó, ú, ñ, à, è, ì, ò, ù (I haven't tried with
others).

This behaviour is reproducible ONLY using O.S. Windows. It has been tested in
Debian and Mac OS X and it works correctly.

Also is different for each mode: 32-bit (DMC stdlib) and 64-bit (MVSC
stdlib).In both, the line is not read properly (I get a length of 0). On
32-bit, the program exits immediately, indicating it cannot read any more data.
On 64-bit, the program continues to allow input.

--

[Issue 15845] New: Windows console cannot read properly UTF-8 lines

[via Digitalmars-d-bugs]

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

  Issue ID: 15845
   Summary: Windows console cannot read properly UTF-8 lines
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: jv_vor...@msn.com

module runnable;

import std.stdio;
import std.string : chomp;
import std.experimental.logger;

void doSomethingElse(char[] data)
{
writeln("hello!");
}

int main(string[] args)
{
/* Some fix I found in UTF-8 related problems, I'm using Windows 10 */
version(Windows)
{
import core.sys.windows.windows;
if (SetConsoleCP(65001) == 0)
throw new Exception("failure");
if (SetConsoleOutputCP(65001) == 0)
throw new Exception("failure");
}
FileLogger fl = new FileLogger("log.log");
char[] readerBuffer;

readln(readerBuffer);
readerBuffer = chomp(readerBuffer);

fl.info(readerBuffer.length); /* <- if the readed string contains at least
one UTF-8
char this gets 0, else it prints its
length
   */

if (readerBuffer != "exit")
doSomethingElse(readerBuffer);

/* Also, all the following code doesn't run as expected, the program
doesn't wait for
   you, it executes readln() even without pressing/sending a key */
readln(readerBuffer);
fl.info(readerBuffer.length);
readln(readerBuffer);
fl.info(readerBuffer.length);
readln(readerBuffer);
fl.info(readerBuffer.length);
readln(readerBuffer);
fl.info(readerBuffer.length);
readln(readerBuffer);
fl.info(readerBuffer.length);

return 0;
}

The code above doesn't work properly on windows if you input at least one of
the following chars: á, é, í, ó, ú, ñ, à, è, ì, ò, ù (I haven't tried with
others).

This behaviour is reproducible ONLY using O.S. Windows. It has been tested in
Debian and Mac OS X and it works correctly.

Also is different for each mode: 32-bit (DMC stdlib) and 64-bit (MVSC
stdlib).In both, the line is not read properly (I get a length of 0). On
32-bit, the program exits immediately, indicating it cannot read any more data.
On 64-bit, the program continues to allow input.

--

[Issue 15844] how to create a program for the EK-LM3S8962 board, using the RODOS operating system, Present the time since startup in the board display (hh:mm:ss). Update this time every second and Bli

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

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

--- Comment #1 from ag0ae...@gmail.com ---
This is not a place to ask for how-tos. If you have a question when learning D,
post to the learn group in the forum: http://forum.dlang.org/group/learn

Closing as invalid.

--

[Issue 15844] New: how to create a program for the EK-LM3S8962 board, using the RODOS operating system, Present the time since startup in the board display (hh:mm:ss). Update this time every second an

[via Digitalmars-d-bugs]

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

  Issue ID: 15844
   Summary: how to create a program for the EK-LM3S8962 board,
using the RODOS operating system, Present the time
since startup in the board display (hh:mm:ss). Update
this time every second and Blink the board LED once
every 5 seconds.
   Product: D
   Version: D2
  Hardware: Other
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: varshini@gmail.com

--

[Issue 15839] this.outer is of wrong type

[via Digitalmars-d-bugs]

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

--- Comment #5 from Jacob Carlborg  ---
(In reply to Kenji Hara from comment #4)

> However... of course it's not stable. And as far as I know, there's no way
> to know the number of chains up to reach wanting enclosing scope.

So the best approach would be to pass in the outer reference to the constructor
when creating the anonymous class and use that instead of "this.outer"?

--

[Issue 15843] New: D-type mangling used for extern(C) (extern) function declaration inside function body, on LDC, GDC, and DMD.

[via Digitalmars-d-bugs]

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

  Issue ID: 15843
   Summary: D-type mangling used for extern(C) (extern) function
declaration inside function body, on LDC, GDC, and
DMD.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: lasssa...@gmail.com

Code:
void main() {
extern(C) extern int func(int);
static assert(func.mangleof == "_D1x4mainFZ4funcUiZi");
}

It is mangled as such on all 3 major compilers.

Using "pragma(mangle, "func")" as an attribute for func gives:
x.d(4): Error: unrecognized pragma(mangle)
x.d(6): Error: undefined identifier 'func'
x.d(7): Error: undefined identifier 'func'

Seemingly, the only user-side fix is moving the declaration out of the function
body.

--

[Issue 13933] templatize object.opEquals

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13933
Issue 13933 depends on issue 12537, which changed state.

Issue 12537 Summary: Templatizing opEquals results in infinite recursion in the 
compiler
https://issues.dlang.org/show_bug.cgi?id=12537

   What|Removed |Added

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

--

[Issue 9769] Remove opEquals from Object

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=9769
Issue 9769 depends on issue 12537, which changed state.

Issue 12537 Summary: Templatizing opEquals results in infinite recursion in the 
compiler
https://issues.dlang.org/show_bug.cgi?id=12537

   What|Removed |Added

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

--

[Issue 12537] Templatizing opEquals results in infinite recursion in the compiler

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 12537] Templatizing opEquals results in infinite recursion in the compiler

[via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/a7ff19ae302948c4fd9e71034cc343d784137803
fix Issue 12537 - Templatizing opEquals results in infinite recursion in the
compiler

https://github.com/D-Programming-Language/dmd/commit/c150f4165ea50cd77e5c9e2ee0ef2f4bfd9027bb
Merge pull request #5028 from 9rnsr/fix12537

Issue 12537 - Templatizing opEquals results in infinite recursion in the
compiler

--

[Issue 15832] Crashing program when a helper template function is used to create a template struct

[via Digitalmars-d-bugs]

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

--- Comment #8 from ag0ae...@gmail.com ---
(In reply to Atila Neves from comment #7)
> In the following code, the length is garbage, and uncommenting an assert
> makes the problem move!

I think a garbage reference to the stack explains this well. Any change to the
stack between the Mock construction and a call to dg affects what dg sees when
it dereferences the garbage pointer. Adding/removing almost anything, including
asserts, is going to change what's on the stack.

You can also make the first assert in main fail. Or you can make the second one
pass when trying hard enough:


/* ... as above ... */

void messWithTheStack() {int[][4] x = void; x[0][0] = 42;}

void main() {
//auto m = Mock!(typeof(dg))(dg);
auto m = mock(dg); // this should be equivalent but crashes
assert(dg(3) == 0);
m.returnValue(42);
messWithTheStack();
assert(dg(3) == 42);
}


--

[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"

[via Digitalmars-d-bugs]

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

--- Comment #7 from Kenji Hara  ---
(In reply to Steven Schveighoffer from comment #6)
> Is there any way to define ComponentInfo or SharedString such that info and
> baseClass overlap? I wouldn't think so.

I don't know. So this is funny issue. I'm waiting more information from Manu.

--

[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"

[via Digitalmars-d-bugs]

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

--- Comment #6 from Steven Schveighoffer  ---
(In reply to Kenji Hara from comment #5)
> If there's no unions (overlapped fields), the error print would be a
> compiler bug.
> 
> Honestly I cannot say anything until I see what the "some stuff" actually is.

I would also like to see what is in there, but even without that, the error
report is at least misleading.

Note the error once again:

Error: struct libep.componentdesc.ComponentDesc destructors, postblits and
invariants are not allowed in overlapping fields info and baseClass

And the struct ComponentDesc:

struct ComponentDesc
{
  ComponentInfo info;
  SharedString baseClass;
}

Is there any way to define ComponentInfo or SharedString such that info and
baseClass overlap? I wouldn't think so.

--

[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"

[via Digitalmars-d-bugs]

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

--- Comment #5 from Kenji Hara  ---
(In reply to Steven Schveighoffer from comment #4)
> But what about if there are no unions? Manu says no unions are being used.
> 
> In his code, there is no unions where the error is being printed (info
> conflicts with baseClass).

If there's no unions (overlapped fields), the error print would be a compiler
bug.

Honestly I cannot say anything until I see what the "some stuff" actually is.

--

[Issue 15779] DWARF EH fails when using stack stomping (-gx)

[via Digitalmars-d-bugs]

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

--- Comment #10 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/c388becdb50b78f4201fb1be91813b688ce8bbda
fix Issue 15779 - DWARF EH fails when using stack stomping (-gx)

https://github.com/D-Programming-Language/dmd/commit/2030b4abbe68d2f8b4b0221f15c9d6e065a2e3af
Merge pull request #5579 from MartinNowak/fix15779

--

[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"

[via Digitalmars-d-bugs]

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

--- Comment #4 from Steven Schveighoffer  ---
(In reply to Kenji Hara from comment #3)
> Minimized example code that compiler shows the error message.

But what about if there are no unions? Manu says no unions are being used.

In his code, there is no unions where the error is being printed (info
conflicts with baseClass).

--

[Issue 15825] dmd's -transition=checkimports reports a false positive for tuple __dollar

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dmd/commit/a13a024a02ab62ba88cbe0f87815032d931f3090
fix Issue 15825 - dmd's -transition=checkimports reports a false positive for
tuple __dollar

https://github.com/D-Programming-Language/dmd/commit/cf273f717fb45ae4c0393c2eab7f0c4ed9e6e9ef
Merge pull request #5567 from 9rnsr/fix15825

--

[Issue 15839] this.outer is of wrong type

[via Digitalmars-d-bugs]

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

--- Comment #4 from Kenji Hara  ---
(In reply to Jacob Carlborg from comment #3)
> So it's not representing the this reference of the outer class anymore?

Until 2.070, the builtin .outer property sometimes returned correct class
reference, sometimes invalid one. Test following code with 2.070 or earlier.

import core.stdc.stdio : printf;

interface Runnable {}

class GC
{
this(AnimatedProgress ap)
{
printf("GC.ctor, ap = %p\n", ap);
}
}

class AnimatedProgress
{
void start()
{
printf("start, this = %p\n", this);

version(ng) int a;

auto r = new class Runnable {
void run()
{
printf("run, this.outer = %p\n", this.outer);

GC gc = new GC(this.outer);

version(ng) int b = a;
}
};
r.run();
}
}

void main()
{
auto ap = new AnimatedProgress();
printf("main, ap = %p\n", ap);
ap.start();
}

Without -version=ng, the class reference (instance address) are same, so the
code would work as the author's expected. But with -version=ng, the start()
member function will become a closure, and this.outer will suddenly return a
pointer to the closure environment - of course it's invalid as a class
reference.

Note that, compiler cannot determine whether the start() makes a closure
environment or not at the place where 'this.outer' is used. Because of that,
the .outer property should have void* type, to be consistent with the lexical
scope nesting.

> Is
> it possible to get that behavior somehow?
> 
> This is a huge regression for DWT.

Theoretically the chain of 'outer' can reach to AnimatedProgress class
instance.

Actually in my example code, following code can work in run() function with
-version=ng case.

version(ng) printf("run, *cast(void**)this.outer = %p\n",
*cast(void**)this.outer);
//GC gc = new GC(this.outer);
GC gc = new GC(cast(AnimatedProgress)*cast(void**)this.outer);

However... of course it's not stable. And as far as I know, there's no way to
know the number of chains up to reach wanting enclosing scope.

--

[Issue 7340] inout not resolved for default parameters

[via Digitalmars-d-bugs]

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

Maksim Zholudev  changed:

   What|Removed |Added

 CC||maxim...@gmail.com

--- Comment #1 from Maksim Zholudev  ---
DMD 2.070.2

inout(int) bar(inout(int) y = 0){return y;}
pragma(msg, typeof(bar()));
pragma(msg, typeof(bar(0)));


Output:

inout(int)
int


`inout` qualifier somehow escapes the context of `bar` function.

--

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

[via Digitalmars-d-bugs]

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

Maksim Zholudev  changed:

   What|Removed |Added

 CC||maxim...@gmail.com

--- Comment #1 from Maksim Zholudev  ---
The error message has been changed.

DMD 2.070.2:
test.d(10): Error: cannot modify immutable expression this.x

This is valid behavior if qualified members of classes are supposed to be dealt
as described here:
https://issues.dlang.org/show_bug.cgi?id=9665#c9
I wonder whether this is documented somewhere else.

--

[Issue 7155] inconsistent .stringof

[via Digitalmars-d-bugs]

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

Maksim Zholudev  changed:

   What|Removed |Added

 CC||maxim...@gmail.com
   Hardware|Other   |All
   Severity|normal  |enhancement

--

[Issue 15832] Crashing program when a helper template function is used to create a template struct

[via Digitalmars-d-bugs]

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

--- Comment #7 from Atila Neves  ---
In the following code, the length is garbage, and uncommenting an assert makes
the problem move!


import std.traits;
import std.conv;

int delegate(int) dg;

static this() {
dg = i => i * 2;
}


struct MockScope(T) {
this(T)(ref T oldFunc, T newFunc) {
_oldFuncPtr = 
_oldFunc = oldFunc;
oldFunc = newFunc;
}

~this() {
*_oldFuncPtr = _oldFunc;
}

 private:

T* _oldFuncPtr;
T _oldFunc;
}

struct Mock(T) {
this(ref T func) {
_returns = [ReturnType!T.init];
ReturnType!T inner(ParameterTypeTuple!T values) {
auto ret = _returns[0];
assert(_returns.length < 10, "Weird length1: " ~
_returns.length.to!string);
if(_returns.length > 1) _returns = _returns[1..$];
assert(_returns.length < 10, "Weird length2: " ~
_returns.length.to!string);
return ret;
}
func = 
_scope = MockScope!(T)(func, );
}

void returnValue(V...)(V value) {
_returns.length = 0;
foreach(v; value) _returns ~= v;
// uncomment below and things work
assert(_returns.length < 10, "Weird length3: " ~
_returns.length.to!string);
}

MockScope!T _scope;
ReturnType!T[] _returns;
}

auto mock(T)(ref T f) {
return Mock!T(f);
}

void main() {
//auto m = Mock!(typeof(dg))(dg);
auto m = mock(dg); // this should be equivalent but crashes
assert(dg(3) == 0);
m.returnValue(42);
assert(dg(3) == 42);
}

--

[Issue 7098] Annoying Forward Reference Error When Compiling Multiple Files

[via Digitalmars-d-bugs]

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

Maksim Zholudev  changed:

   What|Removed |Added

 CC||maxim...@gmail.com

--- Comment #1 from Maksim Zholudev  ---
Seems to be fixed before 2.066.1-rc2 (tested on 64-bit Linux).
I was unable to build older releases with Digger: 2.054 fails to build and
2.060 can't find object.d.

--

[Issue 13116] Should not be able to return ref to 'this'

[via Digitalmars-d-bugs]

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

--- Comment #13 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5591

--

[Issue 15832] Crashing program when a helper template function is used to create a template struct

[via Digitalmars-d-bugs]

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

--- Comment #6 from ag0ae...@gmail.com ---
(In reply to Atila Neves from comment #5)
> At least there's a workaround:
> 
> auto m = Mock!T(...);
> return m;
> 
> I believe that the fact that this behaviour is different from the original
> implementation is a compiler bug and would ask for this to reopened.

I'm not sure if it's strictly a bug (against the spec), or if you're relying on
an implementation detail when you assume construction at the destination.
Either way, I agree that it's weird how adding a temporary makes the copy go
away. I see a reasonable enhancement request, at least.

You can reopen issues yourself. However, in this case I think we better open a
new one. Did that here: issue 15842. I've added you to the CC list.

> Also, the memory corruption that resulted from my original implementation
> goes well beyong a delegate referencing gargabe. It was really weird.

If there's anything else going on, could you provide a test case where that's
more obvious? Or maybe point out how the additional corruption is visible in
the code samples we have so far.

--

[Issue 15842] New: struct is being copied when returned directly

[via Digitalmars-d-bugs]

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

  Issue ID: 15842
   Summary: struct is being copied when returned directly
   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
CC: atila.ne...@gmail.com

This is spin-off from issue 15832.

test.d:


import std.stdio;

struct S
{
this(int dummy) {writeln();}
}

S f() {return S(0);}

void main()
{
S s = f();
writeln();
}


The two `writeln`s print different addresses, so the struct is apparently
constructed in a different location and gets copied on return.

Change `f` to this and they print the same address:


S f() {S s = S(0); return s;}


I don't know what the ABI says about this, so this behavior may be allowed by
the spec, but it's weird how adding a temporary makes the copy go away.

--

[Issue 5040] opOpAssign should be automatically visible for types.

[via Digitalmars-d-bugs]

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

Maksim Zholudev  changed:

   What|Removed |Added

 CC||maxim...@gmail.com
   Hardware|x86 |All
 OS|Windows |All
   Severity|normal  |enhancement

--- Comment #1 from Maksim Zholudev  ---
The same can be done with string mixin:

T opIndexOpAssign(string op)(T value, int index)
{
return mixin("contents " ~ op ~ "= value");
}


Anyway, the possibility to call operator as function (regardless whether it is
defined explicitly or not) for both built-in and user-defined types could make
this part of D more consistent.

--

[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"

[via Digitalmars-d-bugs]

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

--- Comment #3 from Kenji Hara  ---
Minimized example code that compiler shows the error message.

struct X
{
this(this) {}
// or: ~this() {}
// or: invariant {}
}

union U // Error
{
X x;
int overlapping;
}

struct S // Error
{
union
{
X x;
int overlapping;
}
}

For U or S, compiler cannot generate destructors, postblits, or invariants
automatically, because the field x typed X overlapping with other fields.

--

[Issue 15833] [REG2.071b] -m32mscoff always fails to link

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

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

--

[Issue 12575] extern(C) mangling ignored inside mixin template

[via Digitalmars-d-bugs]

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

Atila Neves  changed:

   What|Removed |Added

 CC||atila.ne...@gmail.com

--- Comment #2 from Atila Neves  ---
The problem with this workaround is that it fails for `extern(C++)` unless you
use `pragma(mangle, ` with the exact same mangling.

--

[Issue 15832] Crashing program when a helper template function is used to create a template struct

[via Digitalmars-d-bugs]

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

--- Comment #5 from Atila Neves  ---
At least there's a workaround:

auto m = Mock!T(...);
return m;

I believe that the fact that this behaviour is different from the original
implementation is a compiler bug and would ask for this to reopened.

Also, the memory corruption that resulted from my original implementation goes
well beyong a delegate referencing gargabe. It was really weird.

Atila

--

[Issue 15757] D main is a nested function and cannot be accessed

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dmd/commit/35936ea3a5f3bcafebf1fd746a71aca7694e4af6
fix Issue 15757 - D main is a nested function and cannot be accessed

https://github.com/D-Programming-Language/dmd/commit/d7a46615f3849450979c8e5fa384bc7035db8c11
Merge pull request #5574 from 9rnsr/fix15757

Issue 15757 - D main is a nested function and cannot be accessed

--

[Issue 15835] Segfault with typeid call from lazy argument

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dmd/commit/71294c1f4fdfad8d945b5e423e3c1ed02f30409d
fix Issue 15835 - Segfault with typeid call from lazy argument

https://github.com/D-Programming-Language/dmd/commit/39d6bfade540805b32282d6b542d7af8b126ad05
Merge pull request #5585 from 9rnsr/fix15835

Issue 15835 - Segfault with typeid call from lazy argument

--

[Issue 15835] Segfault with typeid call from lazy argument

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--