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. _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
