[Issue 16379] merging coverage sometimes overwrites existing results

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16379

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Martin Nowak  ---
Fixed by https://github.com/dlang/druntime/pull/1629, the merge flag was set in
main after running std.stdio tests which forks. Those forks would then
overwrite the coverage output.

--

[Issue 15857] incorrect checkimports mismatch for overload sets

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15857

--- Comment #9 from Martin Nowak  ---
(In reply to Jacob Carlborg from comment #8)
> This is not fixed in v2.071.1-b2.

Are you sure? The merge is in v2.071.1-b1.

--

[Issue 16379] merging coverage sometimes overwrites existing results

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16379

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from greensunn...@gmail.com ---
The issue seems to be that `doTest` is called 4x for std.stdio - see this PR
with some explanation on this behavior.

https://github.com/dlang/druntime/pull/1629

--

[Issue 16379] New: merging coverage sometimes overwrites existing results

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16379

  Issue ID: 16379
   Summary: merging coverage sometimes overwrites existing results
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

https://github.com/dlang/phobos/pull/4719#issuecomment-239184919

Running phobos unittests with coverage for std.json multiple times correctly
merges the results.
generated/linux/debug/64/unittest/test_runner std.json

Running std.stdio (and only that module) overwrites the std-json.lst file
before rereading this.
generated/linux/debug/64/unittest/test_runner std.stdio

--

[Issue 16318] inherit from interface via abstract class

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16318

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #1 from b2.t...@gmx.com ---
Your request is not valid because it already works. You forget that an
interface method has to be implemented at least once before being overridden,
otherwise what do you override ? An interface method is not like an abstract
method and the error message couldn't be more accurate.

°
interface Foo
{
void foo();
}

abstract class Bar: Foo {}

class Baz: Bar
{
void foo(uint i){}
void foo(){}
}

void main()
{
(cast(Foo) new Baz).foo;
}
°

I let you close.

--

[Issue 16376] The specifications miss for overload resolution order in mixin templates

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16376

b2.t...@gmx.com changed:

   What|Removed |Added

Summary|The specifications misses   |The specifications miss for
   |for overload resolution |overload resolution order
   |order in mixin templates|in mixin templates

--

[Issue 16378] Cases where empty statements warning is not emitted

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16378

b2.t...@gmx.com changed:

   What|Removed |Added

Summary|Cases where empty   |Cases where empty
   |statements warnings not |statements warning is not
   |emitted |emitted

--

[Issue 16378] New: Cases where empty statements warnings not emitted

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16378

  Issue ID: 16378
   Summary: Cases where empty statements warnings not emitted
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: trivial
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

For these sources

°°
void main()
{struct A{;}}
°°
void main()
{};°°

> Warning: use '{ }' for an empty statement, not a ';'

Should be emitted when the -w switch is passed to dmd.

--

[Issue 16377] New: Make --DRT GC profile information available outside of GC destruction

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16377

  Issue ID: 16377
   Summary: Make --DRT GC profile information available outside of
GC destruction
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: acehr...@yahoo.com

Today, the results of "--DRT-gcopt=profile:1" are printed during GC
destruction, which may never happen e.g. when the application exits with
exit().

Please make the results available through a function call which would enable
registering with atexit() as well as taking snapshots of the profile
information at arbitrary times.

(Also see bug 15602.)

Ali

--

[Issue 16376] New: The specifications misses for overload resolution order in mixin templates

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16376

  Issue ID: 16376
   Summary: The specifications misses for overload resolution
order in mixin templates
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

In this code

template F1(T)
{
   void bar() {}
}

template F2(T)
{
   mixin F1!T;
   void foo() { bar(); } // F3.bar or F1.bar ?
}

template F3(T)
{
   mixin F2!T;
   void bar() {} //

}

struct F4(T)
{
mixin F3!T;
}

the specifications don't state which bar() will be called in this case. While
an identified mixin allows to call accurately one of the overload the default
behavior is not at all specified. 

We would expect the manual to explain which rule is followed in this case even
if the rule is "no rule".

--

[Issue 16375] New: Computing finite ranges with std.range.recurrence

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16375

  Issue ID: 16375
   Summary: Computing finite ranges with std.range.recurrence
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: jens.k.muel...@gmx.de

Assume you have a recurrence that is finite, i.e., you know how to compute the
next value from previous values but in total there are only finite many values.
To me std.range.recurrence looks like a perfect fit to tackle the problem. But
it turns out recurrence does not work with finite ranges when you access the
last element.

unittest
{
static auto next(R)(R states, size_t n)
{
if (n <= 1) return states[n - 1] + 1;
// recurrence with finite elements
// only two elements in this case
assert(false);
}

import std.range : recurrence, take;
import std.algorithm : count;
auto firstNumbers = recurrence!next(0);
assert(firstNumbers.take(2).count() == 2); // fails
// because when accessing an element of a recurrence the next
// element is computed; what if there is no next element, i.e., the
// recurrence range is finite
}

--

[Issue 16370] outdated spec: templated functions allowed in interfaces and functions

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16370

--- Comment #6 from Jonathan M Davis  ---
Well, that's a definite improvement then. It means that I can move a bunch of
unit testing functions into unittest blocks where they belong.

--

[Issue 14619] foreach implicitly slices ranges

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14619

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||lodov...@giaretart.net

--- Comment #2 from Steven Schveighoffer  ---
*** Issue 16374 has been marked as a duplicate of this issue. ***

--

[Issue 16374] Foreach lowering tries opSlice before range primitives

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16374

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |DUPLICATE

--- Comment #1 from Steven Schveighoffer  ---
I actually think this is a duplicate of the other issue. Basically the same
problem, just different reasons why we shouldn't do it :)

*** This issue has been marked as a duplicate of issue 14619 ***

--

[Issue 16370] outdated spec: templated functions allowed in interfaces and functions

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16370

--- Comment #5 from Steven Schveighoffer  ---
Tested with this, and it compiled:

void main()
{
int foo(T)(T t)
{
return 1;
}

foo(0);
foo("hi");
}

--

[Issue 15939] GC.collect causes deadlock in multi-threaded environment

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15939

--- Comment #22 from Илья Ярошенко  ---
(In reply to Martin Nowak from comment #21)
> Nope, that doesn't seem to be the problem.
> All the thread exit code synchronizes on Thread.slock_nothrow.
> It shouldn't even be possible to send a signal to an exiting thread, b/c
> they get removed from the thread list before that, and that is synchronized
> around the suspend loop.
> 
> Might still be a problem with the synchronization of m_isRunning and/or
> thread_cleanupHandler. Did your apps by any chance use thread cancellation
> or pthread_exit?

No, but an Exception may be thrown in a thread.

--

[Issue 15939] GC.collect causes deadlock in multi-threaded environment

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15939

--- Comment #21 from Martin Nowak  ---
Nope, that doesn't seem to be the problem.
All the thread exit code synchronizes on Thread.slock_nothrow.
It shouldn't even be possible to send a signal to an exiting thread, b/c they
get removed from the thread list before that, and that is synchronized around
the suspend loop.

Might still be a problem with the synchronization of m_isRunning and/or
thread_cleanupHandler. Did your apps by any chance use thread cancellation or
pthread_exit?

--

[Issue 16370] outdated spec: templated functions allowed in interfaces and functions

2016-08-11 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16370

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #4 from Jonathan M Davis  ---
(In reply to Steven Schveighoffer from comment #3)
> The limitation that templates can't be inside functions also is no longer
> true!

IIRC, it at least _was_ the case that you could put a template in a function
but that you could only instantiated it once (which was _very_ annoying for
unit testing). Has that changed? Walter didn't agree that it was a problem and
didn't want to change it. I _thought_ that I'd opened a bug on it, but I can't
find it now (be it closed or open).

--