see todo comment:
https://github.com/dlang/druntime/blob/v2.099.0/src/core/runtime.d#L614-L617
// Exception originates in the same module, don't print
// the stack trace.
// TODO: omit stack trace only if assert was thrown
// directly by the unittest.
added in https://github.com/dlang/druntime/pull/2611
before that PR, failing unittests would always print a stack trace - now, the stack trace is omitted for all asserts originating from the same module
// test.d
// run with: dmd -main -unittest -run test.d
void fn() { assert(0, "oh no"); }
unittest { fn(); }
current output:
test.d(1): [unittest] oh no
1/1 modules FAILED unittests
this example should print the stack trace since the assert() wasn't in the unittest block itself
Comment #1 by duser — 2022-03-26T15:12:21Z
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)
Comment #2 by schveiguy — 2024-01-24T16:54:25Z
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.
Comment #3 by robert.schadek — 2024-12-07T13:41:55Z