[Issue 14453] segfault in release mode
https://issues.dlang.org/show_bug.cgi?id=14453 drug007 drug2...@bk.ru changed: What|Removed |Added CC||drug2...@bk.ru --- Comment #1 from drug007 drug2...@bk.ru --- dmd 2.066.1 segfaults too, ldc 2.066.1 and merge-2.067 don't segfault --
[Issue 14452] [REG2.067] Floating point invalid operation when returning a structure containing a float field
https://issues.dlang.org/show_bug.cgi?id=14452 Ivan Kazmenko ga...@mail.ru changed: What|Removed |Added CC||ga...@mail.ru --- Comment #3 from Ivan Kazmenko ga...@mail.ru --- I also get the exception with this code on Windows with dmd 2.067.0 compiling to 32-bit. When compiling to 64-bit or using dmd 2.066.1, everything is fine. --
[Issue 259] Comparing signed to unsigned does not generate an error
https://issues.dlang.org/show_bug.cgi?id=259 --- Comment #59 from Lionello Lunesu lio+bugzi...@lunesu.com --- It's currently using the C integer promotion rules, which are consistent (they're rules after all) but far from simple. --
[Issue 259] Comparing signed to unsigned does not generate an error
https://issues.dlang.org/show_bug.cgi?id=259
Dominikus Dittes Scherkl domini...@scherkl.de changed:
What|Removed |Added
CC||domini...@scherkl.de
--- Comment #58 from Dominikus Dittes Scherkl domini...@scherkl.de ---
The problem is still there, and the behaviour is completely inconsistent, so
braking any code isn't a problem I think because I cannot imagine that anybody
really relies on the strange behaviour:
unittest
{
byte a = -3;
ubyte b = 2;
short c = -3;
ushort d = 2;
inte = -3;
uint f = 2;
long g = -3;
ulong h = 2;
assert(a b);
assert(c d);
assert(e f); // fails!!
assert(g h); // fails!!
assert(a h); // fails!!
assert(b g);
assert(d e);
}
So why don't we change to something that simply always works?
int opCmp(T, U)(const(T) a, const(U) b) pure @safe @nogc nothrow
if(is(Unqual!T == Unqual!U) || isFloatingPoint!T || isFloatingPoint!U)
{
// Should be buildin. Naive implementation:
return a = b ? a != b ? -1 : 0 : 1;
}
/// Returns negative value if a b, 0 if they are equal or positive value if a
b.
/// This will always yield a correct result, no matter which integral types are
compared.
/// It uses one extra comparison operation if and only if
/// one type is signed and the other unsigned but has bigger max.
int opCmp(T, U)(const(T) a, const(U) b) pure @safe @nogc nothrow
if(isIntegral!T isIntegral!U !is(Unqual!T == Unqual!U))
{
static if(T.sizeof == U.sizeof) alias C = Unsigned!T;
else alias C = CommonType!(T, U); // this will be the larger type
static if(isSigned!T isUnsigned!U T.sizeof = U.sizeof)
{
return (a 0) ? -1 : opCmp(cast(Unsigned!C)a, cast(C)b);
}
else static if(isUnsigned!T isSigned!U T.sizeof = U.sizeof)
{
return (b 0) ? 1 : opCmp(cast(C)a, cast(Unsigned!C)b);
}
else
{
// both signed or both unsigned or the unsigned type is smaller
// and can therefore be safely cast to the signed type
return opCmp(cast(C)a, cast(C)b);
}
}
--
[Issue 13920] DMD crash when trying to set a delegate from __traits(getOverloads)
https://issues.dlang.org/show_bug.cgi?id=13920 bb.t...@gmx.com changed: What|Removed |Added Status|RESOLVED|CLOSED --
[Issue 14455] New: [Reg 2.068-devel] std.string.indexOf no longer accepts static arrays
https://issues.dlang.org/show_bug.cgi?id=14455 Issue ID: 14455 Summary: [Reg 2.068-devel] std.string.indexOf no longer accepts static arrays Product: D Version: unspecified Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: c...@dawg.eu This was introduced with a pull request to support any kind of range for indexOf. https://github.com/D-Programming-Language/phobos/pull/3172#issuecomment-93416917 --
[Issue 259] Comparing signed to unsigned does not generate an error
https://issues.dlang.org/show_bug.cgi?id=259 --- Comment #61 from Stewart Gordon s...@iname.com --- (In reply to Dominikus Dittes Scherkl from comment #58) The problem is still there, and the behaviour is completely inconsistent, so braking any code isn't a problem I think because I cannot imagine that anybody really relies on the strange behaviour: Exactly, because it won't break any code. It will cause code that is already broken to correctly error. --
[Issue 14456] New: dmd doesn't call C functions with large structures correctly
https://issues.dlang.org/show_bug.cgi?id=14456 Issue ID: 14456 Summary: dmd doesn't call C functions with large structures correctly Product: D Version: D1 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: andrew.steven...@sociomantic.com Created attachment 1513 -- https://issues.dlang.org/attachment.cgi?id=1513action=edit example code On Linux/amd64 an argument to a C function which is a structure larger than 64 bits should be passed across multiple registers. Making this call with DMD however does something else (probably trying to pass on the stack). I attach some example code to demonstrate the problem. make c produces a binary from C code and make d produces a binary from D calling into C. Both should produce the same output. I currently use a workaround of calling the C function via inline ASM. The correct ASM for the attached example would be something like: mov RDI, qword ptr a; mov RSI, qword ptr a + 8; call prettify; --
[Issue 14456] dmd doesn't call C functions with large structures correctly
https://issues.dlang.org/show_bug.cgi?id=14456 Andrew Stevenson andrew.steven...@sociomantic.com changed: What|Removed |Added Keywords||industry, wrong-code --
[Issue 14456] dmd doesn't call C functions with large structures correctly
https://issues.dlang.org/show_bug.cgi?id=14456 --- Comment #1 from Andrew Stevenson andrew.steven...@sociomantic.com --- This will probably be a specific case of https://issues.dlang.org/show_bug.cgi?id=5570 --
[Issue 14454] New: Lambda template param doesn't compile with -inline *** is a nested function and cannot be accessed from ***
https://issues.dlang.org/show_bug.cgi?id=14454
Issue ID: 14454
Summary: Lambda template param doesn't compile with -inline
*** is a nested function and cannot be accessed from
***
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: dzug...@gmail.com
class Boo(alias func) {}
class Foo
{
final auto Try()
{
return new Boo!((x) { return x; })();
}
}
void main()
{
auto a = new Foo().Try();
}
dmd main.d works, dmd -inline main.d doesn't with main.d(7): Error:
function main.Foo.Try is a nested function and cannot be accessed from D main.
v.2.067. The culprit is the lambda param, using normal function works. Using
return new Boo!(function int(int x) { return x; })(); works too. Using
return new Boo!(function (x) { return x; })(); doesn't work.
--
[Issue 259] Comparing signed to unsigned does not generate an error
https://issues.dlang.org/show_bug.cgi?id=259 --- Comment #60 from Dominikus Dittes Scherkl domini...@scherkl.de --- (In reply to Lionello Lunesu from comment #59) It's currently using the C integer promotion rules, which are consistent (they're rules after all) but far from simple. Ah, ok. I see why ab and cd work - they are all promoted to int. But never the less: who would be affected by changing the behaviour for int and long? Is really anybody relying on that? And sure that was not a bug from the beginning? I don't think that we really should keep bugs just to be consistend with C. -- this is a case where a compiler warning is good: Comparing signed with unsigned values. This works in D but may be a performance issue and behaves different from C. Is this intended? (of course works only after the fix :-) --
[Issue 14376] [REG2.064] false positive Error: one path skips field
https://issues.dlang.org/show_bug.cgi?id=14376 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/7b6fbfac6b0ace5628dbee85fa6eabfd36f585df Merge pull request #4557 from 9rnsr/fix14376 [REG2.064] Issue 14376 - false positive Error: one path skips field Conflicts: src/expression.c --
[Issue 14440] [REG2.067] [CTFE] Wrong values set in a matrix constructor
https://issues.dlang.org/show_bug.cgi?id=14440 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/56c8b67cb084f575c34555cb19dfae12e1b2a726 Merge pull request #4583 from 9rnsr/fix14440 [REG2.067] Issue 14440 - [CTFE] Wrong values set in a matrix constructor --
[Issue 14344] [REG2.067] Wrong opBinary call in construction
https://issues.dlang.org/show_bug.cgi?id=14344 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8ecc06d18422b34c051560bd298f7d8299ea3e78 Merge pull request #4519 from 9rnsr/fix14344 [REG2.067] Issue 14344 - Wrong opBinary call in construction --
[Issue 14396] [REG2.066] compile error std.conv.parse!int with input range
https://issues.dlang.org/show_bug.cgi?id=14396 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14395] [REG2.067] Typesafe variadic function call collapsed if being used for default value
https://issues.dlang.org/show_bug.cgi?id=14395 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1efec7b7aebb7581ece00c8cc1305d2e9c5fc735 Merge pull request #4551 from 9rnsr/fix14395 [REG2.067] Issue 14395 - Typesafe variadic function call collapsed if being used for default value --
[Issue 14396] [REG2.066] compile error std.conv.parse!int with input range
https://issues.dlang.org/show_bug.cgi?id=14396 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/99da04d9af3a4e44d8576445c06d701fe6fdada4 fix Issue 14396 - compile error std.conv.parse!int with input range (dmd2.067) https://github.com/D-Programming-Language/phobos/commit/99956f90609d1d23c5612ba6d4f58b8f951e914d Merge pull request #3183 from aG0aep6G/14396-stable fix Issue 14396 - compile error std.conv.parse!int with input range (dmd... --
[Issue 13920] DMD crash when trying to set a delegate from __traits(getOverloads)
https://issues.dlang.org/show_bug.cgi?id=13920 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|CLOSED |RESOLVED --
[Issue 14423] struct destructors not finalized for AA values
https://issues.dlang.org/show_bug.cgi?id=14423 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/cfcf7480b2faea0af9ab6ddba8e3b0d9f05c4415 Merge pull request #1212 from rainers/aa_entry_typeinfo fix Issue 14423 - struct destructors not finalized for AA values --
[Issue 10490] Type enum in std.variant.Algebraic for final switches
https://issues.dlang.org/show_bug.cgi?id=10490
Justin Whear jus...@economicmodeling.com changed:
What|Removed |Added
CC||jus...@economicmodeling.com
--- Comment #2 from Justin Whear jus...@economicmodeling.com ---
I've been using this solution, perhaps it should be included in std.variant,
though possibly with a better name:
import std.variant;
import std.traits : isInstanceOf;
/**
* Calls the correct overload of Fun based on the runtime value of the Variant
value.
*/
auto applyToAlgebraic(alias Fun, Value)(Value value)
if (isInstanceOf!(VariantN, Value)) // Can we constrain to Algebraic only?
{
foreach (T; Value.AllowedTypes) // unrolled at CT
if (typeid(T) is value.type)
return Fun(value.get!T);
assert(0);
}
--
[Issue 14425] Indirect template instantiation within is expression causes missing linker symbols
https://issues.dlang.org/show_bug.cgi?id=14425 --- Comment #3 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/37da110ed629b493970b6e3170e38ee6e78b2e04 fix Issue 14425 - Indirect template instantiation within is expression causes missing linker symbols https://github.com/D-Programming-Language/dmd/commit/95ff133b423813a0f4b11c7c1369a22536d002d9 Merge pull request #4587 from 9rnsr/fix14425 Issue 14425 - Indirect template instantiation within is expression causes missing linker symbols --
[Issue 14443] [Reg 2.067.0] Incorrect double freeing of reference counted struct
https://issues.dlang.org/show_bug.cgi?id=14443 --- Comment #1 from Martin Nowak c...@dawg.eu --- Regression was apparently introduced with https://github.com/D-Programming-Language/dmd/pull/4078. --
[Issue 4179] [AA] Deleting items from an associative array iterated over
https://issues.dlang.org/show_bug.cgi?id=4179 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added CC||and...@erdani.com --- Comment #12 from Andrei Alexandrescu and...@erdani.com --- We've just had this issue at work, looks like undefined behavior. An associative array with keys deleted during iteration caused crashes without stack trace and without core dump. The right thing here is to throw an exception if an AA is removed from during an iteration. --
[Issue 14427] Regression: navigation for phobos documentation has disappeared
https://issues.dlang.org/show_bug.cgi?id=14427 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #3 from Martin Nowak c...@dawg.eu --- The rsync issue has been resolved by now (was a permission problem). Can we close this? --
[Issue 14457] New: Algebraic does not allow assignment from subset type
https://issues.dlang.org/show_bug.cgi?id=14457
Issue ID: 14457
Summary: Algebraic does not allow assignment from subset type
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: jus...@economicmodeling.com
The following code produces a compilation error, despite the type B allowing a
strict subset of A's type. I would expect this assignment to copy over the
type and storage from `b`, leaving `a` as a `double` equal to `6.0`.
-
import std.variant;
void main(string[] args)
{
alias A = Algebraic!(int, float, double);
A a = 1;
alias B = Algebraic!(int, double);
B b = 6.0;
a = b;
}
-
src/phobos/std/variant.d(605): Error: static assert Cannot store a
VariantN!(8LU, int, double) in a VariantN!(8LU, int, float, double). Valid
types are (int, float, double)
test_algebraic.d(11):instantiated from here: opAssign!(VariantN!(8LU,
int, double))
--
[Issue 4179] [AA] Deleting items from an associative array iterated over
https://issues.dlang.org/show_bug.cgi?id=4179 --- Comment #13 from Ivan Kazmenko ga...@mail.ru --- (In reply to Andrei Alexandrescu from comment #12) We've just had this issue at work, looks like undefined behavior. An associative array with keys deleted during iteration caused crashes without stack trace and without core dump. The right thing here is to throw an exception if an AA is removed from during an iteration. Not just removal. Even *adding* (not deleting) elements to associative array can cause reallocation and undefined behavior as well: https://issues.dlang.org/show_bug.cgi?id=12218 --
[Issue 14458] New: very slow ubyte[] assignment (dmd doesn't use memset)
https://issues.dlang.org/show_bug.cgi?id=14458
Issue ID: 14458
Summary: very slow ubyte[] assignment (dmd doesn't use memset)
Product: D
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
Tracked down a severe performance issue in my new AA implementation, where it
zeroed a freshly allocated entry.
DMD generates the following code for the assignment.
void zero(ubyte[] ary) { ary[] = 0; }
mov rcx, rdi; 0008 _ 48: 89. F9
xor rax, rax; 000B _ 48: 31. C0
mov rdi, rsi; 000E _ 48: 8B. FE
rep stosb ; 0011 _ F3: AA
This is a bytewise store 0 and is about 4x slower than memset, if sz = 4. It's
slightly faster for sz 4.
Not sure why `rep stosb` suddenly becomes 4x slower when sz increases from 3 to
4 bytes, but in any case the compiler should optimize the small case to direct
assignments and the big case to memset, or always use memset.
--
[Issue 14427] Regression: navigation for phobos documentation has disappeared
https://issues.dlang.org/show_bug.cgi?id=14427 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrei Alexandrescu and...@erdani.com --- yes thx --
[Issue 14373] std.range.refRange doesn't work on mere input ranges
https://issues.dlang.org/show_bug.cgi?id=14373 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14373] std.range.refRange doesn't work on mere input ranges
https://issues.dlang.org/show_bug.cgi?id=14373 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/ca4e7d22ecdc53d1529fd88c71ff94198ac44303 fix Issue 14373 - std.range.refRange doesn't work on mere input ranges https://github.com/D-Programming-Language/phobos/commit/f4894c6302286c95fc63b48bdffeb1d658f5cd7a Merge pull request #3123 from aG0aep6G/14373 fix Issue 14373 - std.range.refRange doesn't work on mere input ranges --
[Issue 14459] New: String literal merge bug causes incorrect runtime program behavior
https://issues.dlang.org/show_bug.cgi?id=14459
Issue ID: 14459
Summary: String literal merge bug causes incorrect runtime
program behavior
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: critical
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: go...@comcast.net
Created attachment 1514
-- https://issues.dlang.org/attachment.cgi?id=1514action=edit
strlit16bug.d
The front end propagates const char* string literals in such a way that backend
must merge identical constants or else funny things may happen at runtime. The
DMD backend merges string literals but only caches 16 unique strings, so a
carefully crafted program with more than 16 string literals can produce
erroneous results. See attached code, which follows this pattern:
{
const char* s0 = hi0;
const(char)* p0 = s0;
assert(p0 == s0);
const char* s1 = hi1;
const(char)* p1 = s1;
...
const char* s15 = hi15;
const(char)* p15 = s15;
assert(p0 == s0);// ok
const char* s16 = hi16;
const(char)* p16 = s16;
assert(p0 == s0);// fails
}
This was uncovered while digging into an LDC issue #898 and trying to
understand how DMD front end propagates string literals for const char*.
https://github.com/ldc-developers/ldc/issues/898
Output from attached strlit16bug.d
$ dmd --version
DMD64 D Compiler v2.067.0
Copyright (c) 1999-2014 by Digital Mars written by Walter Bright
$ dmd -run strlit16bug
core.exception.AssertError@strlit16bug.d(40): Assertion failure
5 dmd_runN2D2U4 0x00010855ee54 void
strlit16bug.__assert(int) + 44
6 dmd_runN2D2U4 0x00010855ee21 _Dmain + 193
7 dmd_runN2D2U4 0x000108573b94
D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 40
8 dmd_runN2D2U4 0x000108573ad9 void
rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) + 45
9 dmd_runN2D2U4 0x000108573b39 void
rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()
+ 45
10 dmd_runN2D2U4 0x000108573ad9 void
rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) + 45
11 dmd_runN2D2U4 0x000108573a4c _d_run_main + 504
12 dmd_runN2D2U4 0x00010855ee6c main + 20
13 libdyld.dylib 0x7fff8dd375c9 start + 1
14 ??? 0x0001 0x0 + 1
$
--
[Issue 10490] Type enum in std.variant.Algebraic for final switches
https://issues.dlang.org/show_bug.cgi?id=10490 --- Comment #3 from Justin Whear jus...@economicmodeling.com --- Oops, that should use `value.peek!T`, not `value.get!T` --
[Issue 14458] very slow ubyte[] assignment (dmd doesn't use memset)
https://issues.dlang.org/show_bug.cgi?id=14458 --- Comment #1 from Martin Nowak c...@dawg.eu --- Lots of horrible codegen in cod2.c for memset, memcmp, memcpy, strcpy, strcmp. https://github.com/D-Programming-Language/dmd/blob/95ff133b423813a0f4b11c7c1369a22536d002d9/src/backend/cod2.c#L3580 --
[Issue 14456] dmd doesn't call C functions with large structures correctly
https://issues.dlang.org/show_bug.cgi?id=14456 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #2 from yebblies yebbl...@gmail.com --- Which compiler version? DMD 2.067 has several fixes in this area thanks to fuzz testing. --
[Issue 14398] Segfault when nested struct in static array accesses context
https://issues.dlang.org/show_bug.cgi?id=14398 --- 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/e99eb3fa18ca62f9209b8168badd8f42f3055126 fix Issue 14398 - Segfault when nested struct in static array accesses context https://github.com/D-Programming-Language/dmd/commit/5bad2acc86f1bf09d0b5c06bf653b25de0fe38ea Merge pull request #4552 from 9rnsr/fix14398 Issue 14398 - Segfault when nested struct in static array accesses context --
[Issue 11918] pthread_kill should be nothrow
https://issues.dlang.org/show_bug.cgi?id=11918 Joakim db...@joakim.fea.st changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Joakim db...@joakim.fea.st --- This has been addressed since then: https://github.com/D-Programming-Language/druntime/blame/master/src/core/sys/posix/signal.d#L1902 https://github.com/D-Programming-Language/druntime/blame/master/src/core/sys/osx/pthread.d#L18 --
[Issue 14281] duplicate .debug_info entries for arrays, delegates and aa's
https://issues.dlang.org/show_bug.cgi?id=14281 --- 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/5229aa40d34d9e757fca7d09ee3b0d00fac0d477 fix Issue 14281 - duplicate .debug_info entries for arrays, delegates and aa's - the duplicates exist because DW_AT_sibling pointers are unique for each entry and thus the hashing cache doesn't work - as DW_AT_sibling hardly provides a benefit when skipping over a few bytes, it's better to remove it - also shrinks debug info by a few percent https://github.com/D-Programming-Language/dmd/commit/42b94b6d07d9cd51a5807c572809102c8b390800 Merge pull request #4493 from MartinNowak/fix14281 fix Issue 14281 - duplicate .debug_info entries for arrays, delegates and aa's --
[Issue 14407] No protection and attributes check for class/struct allocator in NewExp
https://issues.dlang.org/show_bug.cgi?id=14407 --- 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/c8481e5ade15af91d39fc3cdf0cf1a6270b2403f fix Issue 14407 - No protection and attributes check for class/struct allocator in NewExp https://github.com/D-Programming-Language/dmd/commit/ca346f2511a24e3ebfb1b5e7088fd3d616709bbc Merge pull request #4555 from 9rnsr/fix14407 Issue 14407 - No protection and attributes check for class/struct allocator in NewExp --
[Issue 14407] No protection and attributes check for class/struct allocator in NewExp
https://issues.dlang.org/show_bug.cgi?id=14407 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 6613] Can't use empty tuple as default value for variadic template function parameter
https://issues.dlang.org/show_bug.cgi?id=6613 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 2803] template + default argument = doesn't work
https://issues.dlang.org/show_bug.cgi?id=2803 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 6613] Can't use empty tuple as default value for variadic template function parameter
https://issues.dlang.org/show_bug.cgi?id=6613 Issue 6613 depends on issue 2803, which changed state. Issue 2803 Summary: template + default argument = doesn't work https://issues.dlang.org/show_bug.cgi?id=2803 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 2803] template + default argument = doesn't work
https://issues.dlang.org/show_bug.cgi?id=2803 --- Comment #5 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/766e4656c06ffddf0a4f6f4ce5a41d90207a2c57 fix Issue 2803 - template + default argument = doesn't work https://github.com/D-Programming-Language/dmd/commit/596aef690e558e50db01c2abb7e31fbafdfa3d16 Merge pull request #4261 from 9rnsr/fix2803 Issue 2803 - template + default argument = doesn't work --
[Issue 6613] Can't use empty tuple as default value for variadic template function parameter
https://issues.dlang.org/show_bug.cgi?id=6613 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/37d633886a342c621ff4705428480f62cc5ab27a fix Issue 6613 - Can't use empty tuple as default value for variadic template function parameter --
[Issue 14388] ICE with idup-ed struct literal in template argument
https://issues.dlang.org/show_bug.cgi?id=14388 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14388] ICE with idup-ed struct literal in template argument
https://issues.dlang.org/show_bug.cgi?id=14388 --- 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/1ad31830eedeecacac4a10c261a99c2260bd2563 fix Issue 14388 - ICE with idup-ed struct literal in template argument https://github.com/D-Programming-Language/dmd/commit/d5b33f20debb342981b0e7837f966a1423a3db20 Merge pull request #4539 from 9rnsr/fix14388 Issue 14388 - ICE with idup-ed struct literal in template argument --
[Issue 14455] [Reg 2.068-devel] std.string.indexOf no longer accepts static arrays
https://issues.dlang.org/show_bug.cgi?id=14455 Martin Nowak c...@dawg.eu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Nowak c...@dawg.eu --- Fixed by https://github.com/D-Programming-Language/phobos/pull/3191. --
[Issue 4179] [AA] Deleting items from an associative array iterated over
https://issues.dlang.org/show_bug.cgi?id=4179 --- Comment #14 from Steven Schveighoffer schvei...@yahoo.com --- We can rewrite the rehash code to rely more on GC destruction, or alter the opApply/range code to be safer. Perhaps this is the right thing to do regardless. This will probably result in AA's being more likely to cause false pointers. --
