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 problem of unittests being enabled recursively, which slows down iterative compilation time enormously.

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 it's very very tedious work to find the reason for a failing unittest.

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 stacktraces contain no information of the call stack so it's very very tedious work to find the reason for a failing unittest.

I assume this is on windows? Yes its a known issue (I know about it). I Don't know if its filed though. As a workaround you can import "core.sys.windows.stacktrace" into each of your modules. That will force the module system to initialize the stacktracing code before the module ctors. The underlying issue is that the module system does not know about the implicit dependeny of every module on the stacktracing module.

Kind Regards
Benjamin Thaut

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 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 will run before this handler is set, so it's
    //       still possible the app could exit without a stack trace.  If
    //       this becomes an issue, the handler could be set in C main
    //       before the module ctors are run.
    Runtime.traceHandler = &defaultTraceHandler;
}

So a possible workaround would be to either import core.runtime in each of your modules or manually run the line Runtime.traceHandler = &defaultTraceHandler.
Also I find it strange that the trace handler is initialized in a regular module constructor. In my eyes it should be a shared module ctor because the storage behind Runtime.traceHandler is __gshared anyway.

Kind Regards
Benjamin Thaut

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 compilation time enormously.

Doh, correction. I hade made the wrong assumption about separate compilation of unittests. It *only* instantiates unittests in the module I compile and *not* in the unittests contained in the imported modules.

Sorry for disturbance,
Per