https://issues.dlang.org/show_bug.cgi?id=22941

--- Comment #1 from duser@neet.fi ---
seems like the stack trace omitting depends on the formatting of the source file path given on the command line

% dmd -main -unittest -run test.d
test.d(1): [unittest] oh no
1/1 modules FAILED unittests

% dmd -main -unittest -run ./test.d
core.exception.AssertError@./test.d(1): oh no
(... stack trace here)

% dmd -main -unittest -run $PWD/test.d
core.exception.AssertError@/home/human/test.d(1): oh no
(... stack trace here)

omitted if the path is just the filename, not omitted if it includes a directory path

(this explains why i've only seen this happen inconsistently)

--

https://issues.dlang.org/show_bug.cgi?id=22941

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

https://issues.dlang.org/show_bug.cgi?id=22941

Steven Schveighoffer <schveiguy@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@gmail.com
           Assignee|nobody@puremagic.com        |schveiguy@gmail.com

--- Comment #2 from Steven Schveighoffer <schveiguy@gmail.com> ---
I just came across this bizarre problem.

I will work on fixing this. The "heuristic" is deeply flawed and results in very surprising behavior.

e.g.

source/app.d:
```d
unittest
{
   int x;
   assert(x == 1);
}

void main() {}
```


> dmd -g -unittest -run source/app.d
core.exception.AssertError@source/app.d(4): unittest failure
----------------
??:? _d_unittestp [0x55dbfac0f7f1]
source/app.d:4 void app.__unittest_L1_C1() [0x562779f2a73e]
??:? void app.__modtest() [0x55dbfac0f75c]
??:? int core.runtime.runModuleUnitTests().__foreachbody6(object.ModuleInfo*)
[0x55dbfac12be2]
??:? int object.ModuleInfo.opApply(scope int
delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*))
[0x55dbfac18f83]
...
1/1 modules FAILED unittests
> cd source
> dmd -g -unittest -run app.d
app.d(4): [unittest] unittest failure
1/1 modules FAILED unittests

Since I always use dub, I never encountered this, because I always have a source directory. I happened to see it when testing stack frame printing (which is currently broken on mac).

Why is this bad? This is bad because:

a) where the test throws is not necessarily in a unittest block. Unittests can
have nested functions, or be calling other functions inside the module. The
stack trace gives more hints than just the line of failure.
b) The mechanism for checking is insanely wrong. *where the file was compiled
from* should have nothing to do with the behavior of druntime. And even then,
submodules will not trigger this check!

We can do better at printing unittest stack traces (like, only printing stack frames above the unittest function). But for now, we need to reverse this.

--