[Issue 17108] Associative array byKeyValue is unsafe

2017-03-08 Thread via Digitalmars-d-bugs
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

2017-03-08 Thread via Digitalmars-d-bugs
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[].

2017-03-08 Thread via Digitalmars-d-bugs
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[].

2017-03-08 Thread via Digitalmars-d-bugs
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[].

2017-03-08 Thread via Digitalmars-d-bugs
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[].

2017-03-08 Thread via Digitalmars-d-bugs
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[].

2017-03-08 Thread via Digitalmars-d-bugs
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

2017-03-08 Thread via Digitalmars-d-bugs
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

2017-03-08 Thread via Digitalmars-d-bugs
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.

2017-03-08 Thread via Digitalmars-d-bugs
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

2017-03-08 Thread via Digitalmars-d-bugs
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

2017-03-08 Thread via Digitalmars-d-bugs
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"

2017-03-08 Thread via Digitalmars-d-bugs
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

2017-03-08 Thread via Digitalmars-d-bugs
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

2017-03-08 Thread via Digitalmars-d-bugs
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

2017-03-08 Thread via Digitalmars-d-bugs
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

2017-03-08 Thread via Digitalmars-d-bugs
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

2017-03-08 Thread via Digitalmars-d-bugs
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.

2017-03-08 Thread via Digitalmars-d-bugs
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()

--