[Issue 14014] struct init required for zero initialized static arrays
https://issues.dlang.org/show_bug.cgi?id=14014 badlink changed: What|Removed |Added URL||http://forum.dlang.org/thre ||ad/ibmdevyxwkwyqjxerpyn@for ||um.dlang.org CC||andrea.9...@gmail.com --
[Issue 14014] struct init required for zero initialized static arrays
https://issues.dlang.org/show_bug.cgi?id=14014 --- Comment #2 from Kenji Hara --- I think this is a dup of issue 14992. --
[Issue 14859] static declared array with more than 16MB size should be allowed in struct and class declaration
https://issues.dlang.org/show_bug.cgi?id=14859 nx changed: What|Removed |Added Priority|P1 |P2 --
[Issue 15036] New: SimpleDllMain assumes various symbols are available unqualified
https://issues.dlang.org/show_bug.cgi?id=15036
Issue ID: 15036
Summary: SimpleDllMain assumes various symbols are available
unqualified
Product: D
Version: D2
Hardware: All
OS: Windows
Status: NEW
Severity: trivial
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: jakobov...@gmail.com
Code like the following does not compile:
version(Windows)
{
import core.sys.windows.dll : SimpleDllMain;
mixin SimpleDllMain;
}
Because SimpleDllMain depends on dll_process_attach, dll_process_detach,
dll_thread_attach and dll_thread_detach from core.sys.windows.dll. Statically
importing the module, or using a renamed import, would also break the mixin.
It would probably be a robust fix to add:
import core.sys.windows.dll : dll_process_attach, dll_process_detach,
dll_thread_attach, dll_thread_detach;
To the body of the DllMain function inside the mixin.
--
[Issue 14859] static declared array with more than 16MB size should be allowed in struct and class declaration
https://issues.dlang.org/show_bug.cgi?id=14859
bb.t...@gmx.com changed:
What|Removed |Added
CC||bb.t...@gmx.com
--- Comment #1 from bb.t...@gmx.com ---
the OPTLINK restriction (https://issues.dlang.org/show_bug.cgi?id=1542) applies
also here even if it looks like the limit value has changed since 2008.
for example compile this:
---
struct Stuff
{
byte[1024*1024*8] hugeArrayPart_1;
byte[1024*1024*8] hugeArrayPart_2;
byte[1024*1024*8] hugeArrayPart_3;
byte[1024*1024*8] hugeArrayPart_4;
byte[1024*1024*8] hugeArrayPart_5;
byte[1024*1024*8] hugeArrayPart_6;
}
void main(){}
---
and you reach the OPTLINK limit.
--
[Issue 15037] New: method TypeInfo.init shadows built-in init property
https://issues.dlang.org/show_bug.cgi?id=15037
Issue ID: 15037
Summary: method TypeInfo.init shadows built-in init property
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: ag0ae...@gmail.com
Found by Rene Zwanenburg:
http://forum.dlang.org/post/xzfnqpkjsxyrebdhz...@forum.dlang.org
Reduced test case:
static assert(is(typeof(TypeInfo.init) == TypeInfo)); /* fails; should pass */
Rene's test case:
void main()
{
import std.algorithm.mutation : remove;
TypeInfo_Class[] arr;
TypeInfo_Class c;
arr = arr.remove!(a => a is c);
}
The problem is that TypeInfo defines an "init" method which shadows the
built-in init property. This confuses templates when they expect T.init to be
the init value of T. In Rene's code, ElementType is the one trying to use the
init property.
In my opinion, the compiler should reject members called "init". A quick test
shows that it already rejects "sizeof" and "mangleof".
--
[Issue 15038] New: Associative Array .get property const vs immutable
https://issues.dlang.org/show_bug.cgi?id=15038
Issue ID: 15038
Summary: Associative Array .get property const vs immutable
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: l...@luismarques.eu
An associative array of string[string] can't be indexed with .get using a
const(char)[], unlike normal/raw indexing:
void main()
{
string[string] foo = ["k": "v"];
const(char)[] key = "k";
string value;
// if this works...
assert(foo[key] == "v");
// and this works...
string* pValue = key in foo;
value = pValue ? *pValue : null;
assert(value == "v");
// ...then this should work
//assert(foo.get(key, null) == "v");
}
--
[Issue 15039] New: Algebraic cannot store a Typedef along with Typedef'ed type
https://issues.dlang.org/show_bug.cgi?id=15039
Issue ID: 15039
Summary: Algebraic cannot store a Typedef along with Typedef'ed
type
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: kolo...@bk.ru
Reproducible with dmd v2.068.1
Test case:
//
import std.variant;
import std.typecons;
alias IntTypedef = Typedef!int;
alias Obj = Algebraic!(int, IntTypedef, This[]);
void x(Obj obj)
{
obj.visit!(
(int x) => {},
(IntTypedef x) => {},
(Obj[] x) => {},
);
}
void main(){}
//
Produces the following error:
/usr/include/dmd/phobos/std/variant.d(2266,21): Error: static assert "overload
for type 'This[]' hasn't been specified"
/usr/include/dmd/phobos/std/variant.d(2010,54):instantiated from here:
visitImpl!(true, VariantN!(16LU, int, Typedef!(int, 0, null), This[]), function
(int x) => ()
{
}
, function (Typedef!(int, 0, null) x) => ()
{
}
, function (VariantN!(16LU, int, Typedef!(int, 0, null), This[])[] x) => ()
{
}
)
src/app.d(9,8):instantiated from here: visit!(VariantN!(16LU, int,
Typedef!(int, 0, null), This[]))
dmd failed with exit code 1.
However the following code (just without Typedef) compiles just fine:
//
import std.variant;
import std.typecons;
alias IntTypedef = Typedef!int;
alias Obj = Algebraic!(int, This[]);
void x(Obj obj)
{
obj.visit!(
(int x) => {},
(Obj[] x) => {},
);
}
void main(){}
//
You can even have Algebraic!(int, int, This[]) without any problems.
--
[Issue 15031] rdmd should force rebuild when --compiler changes
https://issues.dlang.org/show_bug.cgi?id=15031 Vladimir Panteleev changed: What|Removed |Added Keywords||pull CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev --- https://github.com/D-Programming-Language/tools/pull/175 --
[Issue 15027] cannot pass arguments of type DirEntry to std.file functions
https://issues.dlang.org/show_bug.cgi?id=15027 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14765 --
[Issue 14765] [Reg2.068.0] Rangified functions no longer accept types that implicitly cast to string
https://issues.dlang.org/show_bug.cgi?id=14765 Vladimir Panteleev changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=15027 --
[Issue 15031] rdmd should force rebuild when --compiler changes
https://issues.dlang.org/show_bug.cgi?id=15031 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/tools https://github.com/D-Programming-Language/tools/commit/47faba29cb6642246c672b3021fc9f2ca0fcc0d1 fix Issue 15031 - rdmd should force rebuild when --compiler changes https://github.com/D-Programming-Language/tools/commit/44e843e8bd4206766cccfea9a2988c4df2da9955 Merge pull request #175 from CyberShadow/pull-20150911-145139 fix Issue 15031 - rdmd should force rebuild when --compiler changes --
[Issue 15031] rdmd should force rebuild when --compiler changes
https://issues.dlang.org/show_bug.cgi?id=15031 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15035] Possible regression between 2.068.0 and 2.068.1 (2.068.2-b1 also)
https://issues.dlang.org/show_bug.cgi?id=15035 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev --- Can you reduce the test case to a self-contained program with no external dependencies? --
[Issue 15019] [ICE] Heisencrash with -fPIC and non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev --- Not reproducible on Linux. Why does build.sh have both distort.o and distort.d in DMD's command line? Perhaps that causes the result of successive runs to differ? --
[Issue 15019] [ICE] Heisencrash with -fPIC and non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 --- Comment #2 from ponce --- Created attachment 1549 --> https://issues.dlang.org/attachment.cgi?id=1549&action=edit Repro Kit removed distort.o from command-line It's a mistake that probably happened in reducing. I've removed the "distort.o" from build.sh and the bug still happen. Uploaded updated testcase. --
[Issue 15019] [ICE] Heisencrash with -fPIC and non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 --- Comment #3 from ponce --- Can't reproduce on Windows, where I had to remove the -fPIC flag. --
[Issue 15040] New: showcase curl example doesn't run
https://issues.dlang.org/show_bug.cgi?id=15040
Issue ID: 15040
Summary: showcase curl example doesn't run
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: minor
Priority: P1
Component: dlang.org
Assignee: nob...@puremagic.com
Reporter: jansen.ger...@gmail.com
The sample program on the home page that demonstrates curl+json gives this
error message when the "Run" button is clicked:
Compilation output: (9 Killed)
This doesn't make a very good impression for a casual visitor.
// D is like...
pragma(lib, "curl");
import std.functional, std.json, std.net.curl, std.stdio;
alias getJSON = pipe!(get, parseJSON);
void main()
{
auto json = getJSON(
"itsthisforthat.com/api.php?json");
writefln("So, basically D is like a %s for %s",
json["this"].str, json["that"].str);
}
--
[Issue 15040] showcase curl example doesn't run
https://issues.dlang.org/show_bug.cgi?id=15040 --- Comment #1 from Gerald Jansen --- Hmm, the example "// Round floating point numbers" also crashes, but with message: Compilation error: (255 Unknown signal 255) unable to fork: Cannot allocate memory --
[Issue 15041] New: Pointer slice with one negative index throws 'Range violation'
https://issues.dlang.org/show_bug.cgi?id=15041 Issue ID: 15041 Summary: Pointer slice with one negative index throws 'Range violation' Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: anoneu...@gmail.com When slicing a pointer, if one (not both) of the indices is negative, it throws a Range violation. Tested with DMD 2.068.1 example: auto p = &"a"[5]; assert(p[-1] == 'a'); // no problem assert(p[-3 .. -1] == "aa"); // no problem assert(p[-1 .. 1] == "aa"); // 'Range violation' ( http://dpaste.dzfl.pl/3be7eb85483c ) --
[Issue 15019] [ICE] Heisencrash with -fPIC and non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 --- Comment #4 from Vladimir Panteleev --- Maybe you could try running DMD under Valgrind? --
[Issue 12210] dlang.org home page example - Run button does not work
https://issues.dlang.org/show_bug.cgi?id=12210 Steven Schveighoffer changed: What|Removed |Added CC||jansen.ger...@gmail.com --- Comment #4 from Steven Schveighoffer --- *** Issue 15040 has been marked as a duplicate of this issue. *** --
[Issue 15040] showcase curl example doesn't run
https://issues.dlang.org/show_bug.cgi?id=15040 Steven Schveighoffer changed: What|Removed |Added Status|NEW |RESOLVED CC||schvei...@yahoo.com Hardware|x86_64 |All Resolution|--- |DUPLICATE OS|Linux |All --- Comment #2 from Steven Schveighoffer --- *** This issue has been marked as a duplicate of issue 12210 *** --
[Issue 15035] Possible regression between 2.068.0 and 2.068.1 (2.068.2-b1 also)
https://issues.dlang.org/show_bug.cgi?id=15035 Tomáš Chaloupka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Tomáš Chaloupka --- I've retested this on my linux machine at home with the same results as in #1 so as it works with current beta, I think it's safe to close this. --
[Issue 12210] dlang.org home page example - Run button does not work
https://issues.dlang.org/show_bug.cgi?id=12210 --- Comment #5 from Gerald Jansen --- Okay, so the sample programs often fail to run for timeout or lack of memory and this has been ongoing(?) since November 2013. How could a visitor take a language seriously if the demonstration utility offered front and centre on its home page fails to run even on small examples? Either the server should be upgraded to provide adequate resources or the "feature" should be removed. --
[Issue 15016] Structs with opDispatch cannot be emplaced
https://issues.dlang.org/show_bug.cgi?id=15016 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu Severity|normal |regression --- Comment #1 from Martin Nowak --- This is actually an issue of https://github.com/D-Programming-Language/druntime/pull/1312. --
[Issue 15029] [Reg 2.069.0-devel] _postblitRecurse invokes opDispatch with __xpostblit (breaks emplace)
https://issues.dlang.org/show_bug.cgi?id=15029 Martin Nowak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Nowak --- *** This issue has been marked as a duplicate of issue 15016 *** --
[Issue 15042] New: [REG2.068] isInstanceOf fails when a template argument is an instance of the tested template
https://issues.dlang.org/show_bug.cgi?id=15042
Issue ID: 15042
Summary: [REG2.068] isInstanceOf fails when a template argument
is an instance of the tested template
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: marco.le...@gmx.de
I have a templated struct that emits an error when you pass in something else
than "void" or another instance of itself. The following worked with 2.067, but
fails with 2.068.1:
import std.traits;
struct RC(Parent)
{
static assert (is(Parent == void) || isInstanceOf!(RC, Parent), "This used
to compile in 2.067");
}
alias Regression = RC!(RC!(void));
--
[Issue 15016] Structs with opDispatch cannot be emplaced
https://issues.dlang.org/show_bug.cgi?id=15016 --- Comment #2 from Martin Nowak --- *** Issue 15029 has been marked as a duplicate of this issue. *** --
[Issue 12210] dlang.org home page example - Run button does not work
https://issues.dlang.org/show_bug.cgi?id=12210 --- Comment #6 from Vladimir Panteleev --- The problems you are seeing started recently, see here: http://forum.dlang.org/post/mr5da0$1djk$1...@digitalmars.com --
[Issue 15019] [ICE] Heisencrash with -fPIC and non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 --- Comment #5 from ponce --- Here the valgrind output: http://pastebin.com/vMLUgbK1 --
[Issue 12210] dlang.org home page example - Run button does not work
https://issues.dlang.org/show_bug.cgi?id=12210 --- Comment #7 from Gerald Jansen --- Ah. Sorry for the noise then. Keep up the good work! --
[Issue 12210] dlang.org home page example - Run button does not work
https://issues.dlang.org/show_bug.cgi?id=12210 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #8 from Steven Schveighoffer --- (In reply to Vladimir Panteleev from comment #6) > The problems you are seeing started recently I don't think the compiler upgrade caused the issues, perhaps it fixes the ability to compile some of the code which required a newer compiler, but it appears that the out of memory errors are not new. I honestly don't know, as I have no idea how to test this. --
[Issue 13819] ICE: backend\cg87.c 1495 with mixin, delegate and -O
https://issues.dlang.org/show_bug.cgi?id=13819 ponce changed: What|Removed |Added Summary|Internal error: |ICE: backend\cg87.c 1495 |backend\cg87.c 1495 with|with mixin, delegate and -O |mixin, delegate and -O | --
[Issue 15019] [ICE] Heisencrash with -fPIC and non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 --- Comment #6 from ponce --- Interestingly enough, DMD never crashes if launch through the lldb debugger. --
[Issue 12034] Union and inlining leads to erroneous "Error: variable used before set"
https://issues.dlang.org/show_bug.cgi?id=12034 --- Comment #2 from ponce --- DMD v2.068.0 refuses this program with: test.d(15): Error: variable hu used before set Not sure if intended because the whole variable is written with hu.f = asHalf; --
[Issue 15042] [REG2.068] isInstanceOf fails when a template argument is an instance of the tested template
https://issues.dlang.org/show_bug.cgi?id=15042 --- Comment #1 from Marco Leise --- Digger traced it down to this pull request for #14290: https://github.com/D-Programming-Language/dmd/pull/4499/files#diff-0477a1d81a6a920c99362954179c59c8 --
[Issue 15042] [REG2.068] isInstanceOf fails when a template argument is an instance of the tested template
https://issues.dlang.org/show_bug.cgi?id=15042 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev --- (In reply to Marco Leise from comment #1) > Digger traced it down to this pull request for #14290: > https://github.com/D-Programming-Language/dmd/pull/4499/files#diff- > 0477a1d81a6a920c99362954179c59c8 Confirmed, introduced in https://github.com/D-Programming-Language/dmd/pull/4499 --
[Issue 15019] [ICE] Heisencrash with -fPIC and non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 Jacob Carlborg changed: What|Removed |Added CC||d...@me.com --- Comment #7 from Jacob Carlborg --- Does -fPIC make any difference? Because on OS X PIC is always on. --
[Issue 15019] [ICE] Heisencrash on OS X with non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 ponce changed: What|Removed |Added Summary|[ICE] Heisencrash with |[ICE] Heisencrash on OS X |-fPIC and non-trivial |with non-trivial projects |projects| --
[Issue 15019] [ICE] Heisencrash with -fPIC and non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 --- Comment #8 from ponce --- Indeed it does not. --
[Issue 15019] [ICE] Heisencrash on OS X with non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 --- Comment #9 from ponce --- -g -debug and -w are not necessary to crash -m32 is necessary though --
[Issue 15019] [ICE] Heisencrash on OS X with non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 --- Comment #10 from Jacob Carlborg --- (In reply to ponce from comment #9) > -m32 is necessary though Out of curiosity, what's the use case for 32bit on OS X? --
[Issue 15019] [ICE] Heisencrash on OS X 32-bit with non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 ponce changed: What|Removed |Added Summary|[ICE] Heisencrash on OS X |[ICE] Heisencrash on OS X |with non-trivial projects |32-bit with non-trivial ||projects --
[Issue 15019] [ICE] Heisencrash on OS X with non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 --- Comment #11 from ponce --- Some users in my target market (I don't know the exact proportion) keep using 32-bit audio plugins since if they upgrade to a 64-bit host they have to upgrade all their software plugins. Some of which do not exist in 64-bit. All desktop audio software support 32-bit Mac, to the exception of Apple Logic. LDC also has a bug that prevented 32-bit previously. --
[Issue 15043] New: [e2ir] dmd still crashes when trying to set a delegate from __traits(getOverloads)
https://issues.dlang.org/show_bug.cgi?id=15043
Issue ID: 15043
Summary: [e2ir] dmd still crashes when trying to set a delegate
from __traits(getOverloads)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: ice
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bb.t...@gmx.com
the following program compiled without any particular switch
---
class Foo
{
uint bar(){return 0;}
this()
{
foreach(member; __traits(allMembers, typeof(this)))
foreach(overload; __traits(getOverloads, typeof(this), member))
static if (member == "bar")
setDg(&overload);
}
void setDg(uint delegate() dg){}
}
void main(){}
---
crashes DMD and outputs:
> Error: delegates are only for non-static functions
> Assertion failure: '(int)vindex >= 0' on line 3439 in file 'e2ir.c'
- The bug looks highly related to
https://issues.dlang.org/show_bug.cgi?id=13920.
- The bug only produces a messages since 2.068, previously it was only crashing
without any helpful dignostic message.
--
[Issue 14331] Cannot cast(void*) a class with an alias this struct
https://issues.dlang.org/show_bug.cgi?id=14331
Martin Nowak changed:
What|Removed |Added
CC||c...@dawg.eu
Summary|Can't call `destroy()` on a |Cannot cast(void*) a class
|class with `alias this` on |with an alias this struct
|a struct field |
--- Comment #1 from Martin Nowak ---
cat > bug.d << CODE
class Test
{
static struct S {}
S s;
alias s this;
}
void main()
{
auto p = cast(void*)(new Test);
}
CODE
dmd -c bug
bug2.d(11): Error: cannot cast expression (new Test).s of type S to void*
It is a more general problem that you cannot cast the class to void*.
--
[Issue 15044] New: [Reg 2.068.0] destroy might leak memory
https://issues.dlang.org/show_bug.cgi?id=15044
Issue ID: 15044
Summary: [Reg 2.068.0] destroy might leak memory
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat > bug.d << CODE
struct Vector
{
~this()
{
}
RefCounted!Vector dup()
{
return RefCounted!Vector(&this);
}
}
struct RefCounted(T)
{
~this()
{
.destroy(*t); // __xdtor of Vector not yet available
static assert(__traits(hasMember, T, "__xdtor"));
}
T* t;
}
CODE
dmd -c bug
bug.d(18): Error: static assert (__traits(hasMember, Vector, "__xdtor")) is
false
bug.d(7):instantiated from here: RefCounted!(Vector)
The problem is that __xdtor is not yet available when the destructor of
RefCounted is analyzed, hence .destroy won't call the destructor of Vector.
It seems that the creation of __xdtor should happen earlier.
--
[Issue 15016] Structs with opDispatch cannot be emplaced
https://issues.dlang.org/show_bug.cgi?id=15016 --- Comment #3 from Martin Nowak --- It seems that __traits(parent, s.opDispatch!"__xpostblit") is broken as well. --
[Issue 15016] Structs with opDispatch cannot be emplaced
https://issues.dlang.org/show_bug.cgi?id=15016 --- Comment #4 from Martin Nowak --- And the actual trigger for this bug is a change in hasMember. --
[Issue 15043] [e2ir] dmd still crashes when trying to set a delegate from __traits(getOverloads)
https://issues.dlang.org/show_bug.cgi?id=15043
bb.t...@gmx.com changed:
What|Removed |Added
Severity|major |normal
--- Comment #1 from bb.t...@gmx.com ---
Lowered importance. Actually the problem seems to come from a lValue/rValue
thing because when using an intermediate variable to carry the delegate then
this works:
---
static if (member == "bar")
{
auto dg = &overload; // OK with intermediate value
setDg(dg);
}
---
--
[Issue 15045] New: [Reg 2.069-devel] hasElaborateCopyConstructor is true for struct with opDispatch
https://issues.dlang.org/show_bug.cgi?id=15045
Issue ID: 15045
Summary: [Reg 2.069-devel] hasElaborateCopyConstructor is true
for struct with opDispatch
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat > bug.d << CODE
import std.traits;
struct S
{
void opDispatch(string func, Args...)(Args args)
{
}
}
static assert(!hasElaborateCopyConstructor!S);
CODE
Introduced by https://github.com/D-Programming-Language/phobos/pull/3497.
I'd suggest to fix __traits(hasMember) to not instantiate opDispatch in which
case issue 14605 needs to be refixed.
--
[Issue 15044] [Reg 2.068.0] destroy might leak memory
https://issues.dlang.org/show_bug.cgi?id=15044 --- Comment #1 from Martin Nowak --- This breaks b/c of the following semantic analysis issue. Vector.semantic dup.semantic RefCounted!Vector.semantic (return type) RefCounted!Vector buildOpAssign RefCounted!Vector.dtor.semantic3 (buildOpAssign) It seems that buildOpAssign is too greedy running semantic3 during a semantic1 pass of a struct. --
[Issue 15044] [Reg 2.068.0] destroy might leak memory
https://issues.dlang.org/show_bug.cgi?id=15044 Martin Nowak changed: What|Removed |Added CC||k.hara...@gmail.com --- Comment #2 from Martin Nowak --- Any idea how to solve this @Kenji? We could try to do semantic3 for buildOpAssign later, but then we'd have to add a special case to op_overload and gag assign usage or so. --
[Issue 15019] [ICE] Heisencrash on OS X 32-bit with non-trivial projects
https://issues.dlang.org/show_bug.cgi?id=15019 --- Comment #12 from Vladimir Panteleev --- WIP here, will continue tomorrow: https://github.com/CyberShadow/dmd/commits/valgrind-20150912 --
