On Tuesday, 3 May 2016 at 10:48:51 UTC, Nordlöw wrote:
This is a big problem for me because, in my application, I've
realized unittests as functions called from within static
shared module constructors to elide the problem of unittests
being enabled recursively, which slows down iterative
On Wednesday, 4 May 2016 at 06:37:28 UTC, Nordlöw wrote:
On Tuesday, 3 May 2016 at 12:31:10 UTC, Benjamin Thaut wrote:
I assume this is on windows? Yes its a known issue (I know
No, the problem occurs on my Linux aswell.
From core.runtime:
static this()
{
// NOTE: Some module ctors
On Tuesday, 3 May 2016 at 12:31:10 UTC, Benjamin Thaut wrote:
I assume this is on windows? Yes its a known issue (I know
No, the problem occurs on my Linux aswell.
On Tuesday, 3 May 2016 at 10:52:20 UTC, Nordlöw wrote:
On Tuesday, 3 May 2016 at 10:48:51 UTC, Nordlöw wrote:
AFAICT, stacktraces are not emitted with debug information when
Should be static shared module constructors.
errors occur in static module constructors. Is this a know bug?
My
On Tuesday, 3 May 2016 at 10:48:51 UTC, Nordlöw wrote:
AFAICT, stacktraces are not emitted with debug information when
Should be static shared module constructors.
errors occur in static module constructors. Is this a know bug?
My stacktraces contain no information of the call stack so
AFAICT, stacktraces are not emitted with debug information when
errors occurr in static module constructors. Is this a know bug?
This is a big problem for me because, in my application, I've
realized unittests as functions called from within static shared
module constructors to elide the
