[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 --