[phobos] Silent failure of std.container unittests

[Sean Kelly]

On Jul 13, 2010, at 11:06 PM, Walter Bright wrote:

> 
> 
> Sean Kelly wrote:
>> Walter's change fixed the issue where non-throwing asserts weren't triggering a unittest failure, but it also reverted my change to trap unhandled exceptions, set a "fail" flag, and continue with the next test.  I'd fix this, but what I'm confused about is why the support-non-throwing-asserts change was re-added in the first place.  So instead I'd like to ask what the eventual/intended/desired/whatever behavior is for unit tests so I can work towards that.  I'd like throwing asserts and for each unittest in a module to be run separately so recovery from an AssertError (which I'd like for unit tests) is at the granularity of the unittest block, not the module.  The best I can do without a compiler change is module-level granularity like we have now, but asserts could all throw again, etc.  Should this be an intermediate step?  Should we keep non-throwing asserts?  Halp plzz.
>> 
>>  
> 
> Perhaps what will help is examining the output of the compiler. For the program:

...

> What is happening is that the compiler inserts the address of __D3foo9__modtestFZv into the ModuleInfo record. The druntime calls this function. This function, in turn, runs the unittest code for that module. When a unittest fails, the function __d_unittestm(&__ModuleInfoZ, __LINE__) is called. This function is in the druntime.
> 
> Note that the compiler generated code does not throw any exceptions. What happens when __d_unittestm() is called is ENTIRELY up to druntime, which can be:
> 
> 1. nothing
> 2. print a message
> 3. abort
> 4. throw an exception chosen by druntime
> 5. whatever druntime wants to
> 
> The important thing to note is that this is up to druntime, not the compiler. The part that is up to the compiler is the granularity of the unittests, which is set at the module, not the individual unittest blocks.

Right.  I was proposing that ModuleInfo have a list of unittest modules instead of a reference to a single function which calls them each in turn (ie. finer granularity).  I've already taken care of the assert behavior on my local machine, but I don't want to commit the change unless it's what people want.  I thought that since you reverted my unittest changes yesterday that non-throwing asserts might actually be desired.