[Issue 22941] failing unittest should omit stack trace only if assert was thrown directly by the unittest

[d-bugmail at puremagic.com]

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

Steven Schveighoffer <schveiguy at gmail.com> changed:

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

--- Comment #2 from Steven Schveighoffer <schveiguy at 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 at 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.

--