[Issue 17108] Associative array byKeyValue is unsafe
https://issues.dlang.org/show_bug.cgi?id=17108 --- Comment #2 from hst...@quickfur.ath.cx --- Bah. Regardless of whether the void* cast is allowed or not, _aaRange() is @system so it's still a no-go. --
[Issue 17108] Associative array byKeyValue is unsafe
https://issues.dlang.org/show_bug.cgi?id=17108 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- Hmph. This is caused by the last line in object.byKeyValue()(): /usr/src/d/druntime/import/object.d(2071): Error: cast from int[string] to void* not allowed in safe code test.d(4): Error: template instance object.byKeyValue!(int[string], string, int) error instantiating Could this be a regression? I vaguely recall casting to void* used to be allowed, you just can't dereference it unless you're in @trusted land. --
[Issue 17247] std.bitmanip.read should not assume sliceable range is assign-copyable to ubyte[].
https://issues.dlang.org/show_bug.cgi?id=17247 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/6111a6cb377279912f47bf3e50846715006a9510 Fix issue 17247. https://github.com/dlang/phobos/commit/a312a6a3fbd42442ece375ce95e36da25264b623 Merge pull request #5257 from quickfur/issue17247 Fix issue 17247: std.bitmanip.read should not assume hasSlicing means assign-copyable --
[Issue 17247] std.bitmanip.read should not assume sliceable range is assign-copyable to ubyte[].
https://issues.dlang.org/show_bug.cgi?id=17247 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 17247] std.bitmanip.read should not assume sliceable range is assign-copyable to ubyte[].
https://issues.dlang.org/show_bug.cgi?id=17247 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull --- Comment #2 from hst...@quickfur.ath.cx --- https://github.com/dlang/phobos/pull/5257 --
[Issue 17247] std.bitmanip.read should not assume sliceable range is assign-copyable to ubyte[].
https://issues.dlang.org/show_bug.cgi?id=17247 --- Comment #1 from hst...@quickfur.ath.cx --- In other words, std.bitmanip.read should not assume that slicing a ubyte range will return ubyte[] or similar, since it could be a user-defined type. --
[Issue 17247] New: std.bitmanip.read should not assume sliceable range is assign-copyable to ubyte[].
https://issues.dlang.org/show_bug.cgi?id=17247 Issue ID: 17247 Summary: std.bitmanip.read should not assume sliceable range is assign-copyable to ubyte[]. Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: hst...@quickfur.ath.cx std.bitmanip.read wrongly assumes that if an input range has elements that are implicitly convertible to const(ubyte), and it supports slicing operations, then it is possible to copy range elements to a ubyte[] static array using the assignment operator. Obviously this only works if the range is ubyte[] or a similar built-in type, but it fails horribly for user-defined ubyte ranges that support slicing. --
[Issue 15637] Region allocator assert failure when expanding the last allocation
https://issues.dlang.org/show_bug.cgi?id=15637 Sönke Ludwig changed: What|Removed |Added Assignee|nob...@puremagic.com|and...@erdani.com --
[Issue 15637] Region allocator assert failure when expanding the last allocation
https://issues.dlang.org/show_bug.cgi?id=15637 Sönke Ludwig changed: What|Removed |Added CC||slud...@outerproduct.org Severity|enhancement |normal --
[Issue 17246] Extra destructor call.
https://issues.dlang.org/show_bug.cgi?id=17246 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 16612] Bug in std.regex? in dmd? Segmentation fault
https://issues.dlang.org/show_bug.cgi?id=16612 Dmitry Olshansky changed: What|Removed |Added Status|NEW |RESOLVED CC||dmitry.o...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from Dmitry Olshansky --- Cannot reproduce on DMD v2.074alpha. Try with latest stable could have been a compiler issue. --
[Issue 17075] ctRegex BacktrackingMatcher.prevStack: free(): invalid pointer
https://issues.dlang.org/show_bug.cgi?id=17075 Dmitry Olshansky changed: What|Removed |Added CC||andrew.benton...@gmail.com --- Comment #2 from Dmitry Olshansky --- *** Issue 15593 has been marked as a duplicate of this issue. *** --
[Issue 15593] ctRegex: "munmap_chunk(): invalid pointer"
https://issues.dlang.org/show_bug.cgi?id=15593 Dmitry Olshansky changed: What|Removed |Added Status|NEW |RESOLVED CC||dmitry.o...@gmail.com Resolution|--- |DUPLICATE --- Comment #2 from Dmitry Olshansky --- *** This issue has been marked as a duplicate of issue 17075 *** --
[Issue 17075] ctRegex BacktrackingMatcher.prevStack: free(): invalid pointer
https://issues.dlang.org/show_bug.cgi?id=17075 Dmitry Olshansky changed: What|Removed |Added Keywords||pull CC||dmitry.o...@gmail.com --- Comment #1 from Dmitry Olshansky --- https://github.com/dlang/phobos/pull/5252 --
[Issue 17157] ctRegex.matchAll doesn't set last item in Captures
https://issues.dlang.org/show_bug.cgi?id=17157 Dmitry Olshansky changed: What|Removed |Added Keywords||pull --- Comment #2 from Dmitry Olshansky --- https://github.com/dlang/phobos/pull/5250 --
[Issue 16485] Add trait for determining whether a member variable is static or not
https://issues.dlang.org/show_bug.cgi?id=16485 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/d79da1d3cac16043b3599a234875c20c9a9e7b0c Issue 16485 - Add trait for testing if a member is static. https://github.com/dlang/phobos/commit/eb92dc9a88cc8e3a787a6347bc7c58df62af2637 Merge pull request #5112 from sprinkle131313/is-static-member Issue 16485 - Add trait for testing if a member is static. merged-on-behalf-of: Jack Stouffer --
[Issue 13156] `abstract` attribute should be disallowed in `interface`s
https://issues.dlang.org/show_bug.cgi?id=13156
b2.t...@gmx.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||b2.t...@gmx.com
Resolution|--- |INVALID
--- Comment #1 from b2.t...@gmx.com ---
interface I{void a();}
static assert(__traits(isAbstractFunction, I.a));
--
[Issue 17157] ctRegex.matchAll doesn't set last item in Captures
https://issues.dlang.org/show_bug.cgi?id=17157 Dmitry Olshansky changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #1 from Dmitry Olshansky --- (In reply to Alexey Kulentsov from comment #0) > if comment at line 6 beginning is removed and ctRegex is used then we have > exception: > > core.exception.AssertError@/usr/include/dmd/phobos/std/regex/package.d(565): > wrong match: 1..0 > > ??:? _d_assert_msg [0x4edba6] > ??:? std.regex.Captures!(immutable(char)[], > ulong).Captures.opIndex!().opIndexinout(pure nothrow @trusted > inout(immutable(char)[]) function(ulong)) [0x4e4f01] > ??:? _Dmain [0x4bb73e] > ??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv > [0x4ef333] > ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int > function(char[][])*).tryExec(scope void delegate()) [0x4ef25b] > ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int > function(char[][])*).runAll() [0x4ef2d8] > ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int > function(char[][])*).tryExec(scope void delegate()) [0x4ef25b] > ??:? _d_run_main [0x4ef1c7] > ??:? main [0x4eae0f] > ??:? __libc_start_main [0xc012282f] > > More experiments have shown: last element of match is not set and attempt to > access it leads to exception. > > Compiler: DMD64 D Compiler v2.073.0 > OS: Ubuntu 16.04 LTS Trying to reproduce with latest master (2.074~alpha) I see no exception but the output of 2 runs differs. With regex correctly: 0:a 1:a 2: 3: 4: 0:b 1: 2:b 3: 4: 0:c 1: 2: 3:c 4: 0:d 1: 2: 3: 4:d With ctRegex: 0:a 1:a 2: 3: 4: 0:b 1:a 2:b 3: 4: 0:c 1:a 2: 3:c 4: 0:d 1:a 2: 3: 4:d Investigating... --
[Issue 17246] New: Extra destructor call.
https://issues.dlang.org/show_bug.cgi?id=17246
Issue ID: 17246
Summary: Extra destructor call.
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: jappleg...@gmail.com
import std.stdio;
struct Foo {
int val;
this(int val) {
writefln("%s.this(int)", val);
this.val = val;
}
this(this) {
writefln("%s.this(this)", val);
this.val = val;
}
~this() {
writefln("%s.~this()", val);
this.val = val;
}
}
struct Bar {
Foo foo;
this(Foo foo, bool) { this.foo = foo; }
}
bool fun(bool val) { return !val; }
auto genBar(bool flag) {
return flag ? Bar() : Bar(Foo(10), fun(!flag));
}
void main(string[] args) {
auto bar = genBar(args.length == 0);
}
Compiler generates extra destructor call:
10.this(int)
10.this(this)
10.~this()
10.~this()
10.~this()
If we slightly change function genBar:
auto genBar(bool flag) {
auto a = flag ? Bar() : Bar(Foo(10), fun(!flag));
return a;
}
or
auto genBar(bool flag) {
return flag ? Bar() : Bar(Foo(10), false);
}
then output looks as expected:
10.this(int)
10.this(this)
10.~this()
10.~this()
--
