Want to help DMD bugfixing? Write a simple utility.

[Jonathan M Davis]

On Saturday 19 March 2011 18:04:57 Don wrote:
> Jonathan M Davis wrote:
> > On Saturday 19 March 2011 17:11:56 Don wrote:
> >> Here's the task:
> >> Given a .d source file, strip out all of the unittest {} blocks,
> >> including everything inside them.
> >> Strip out all comments as well.
> >> Print out the resulting file.
> >> 
> >> Motivation: Bug reports frequently come with very large test cases.
> >> Even ones which look small often import from Phobos.
> >> Reducing the test case is the first step in fixing the bug, and it's
> >> frequently ~30% of the total time required. Stripping out the unit tests
> >> is the most time-consuming and error-prone part of reducing the test
> >> case.
> >> 
> >> This should be a good task if you're relatively new to D but would like
> >> to do something really useful.
> > 
> > Unfortunately, to do that 100% correctly, you need to actually have a
> > working D lexer (and possibly parser). You might be able to get
> > something close enough to work in most cases, but it doesn't take all
> > that much to throw off a basic implementation of this sort of thing if
> > you don't lex/parse it with something which properly understands D.
> > 
> > - Jonathan M Davis
> 
> I didn't say it needs 100% accuracy. You can assume, for example, that
> "unittest" always occurs at the start of a line. The only other things
> you need to lex are {}, string literals, and comments.
> 
> BTW, the immediate motivation for this is std.datetime in Phobos. The
> sheer number of unittests in there is an absolute catastrophe for
> tracking down bugs. It makes a tool like this MANDATORY.

I tried to create a similar tool before and gave up because I couldn't make it 
100% accurate and was running into problems with it. If someone wants to take a 
shot at it though, that's fine.

As for the unit tests in std.datetime making it hard to track down bugs, that 
only makes sense to me if you're trying to look at the whole thing at once and 
track down a compiler bug which happens _somewhere_ in the code, but you don't 
know where. Other than a problem like that, I don't really see how the unit 
tests get in the way of tracking down bugs. Is it that you need to compile in a 
version of std.datetime which doesn't have any unit tests compiled in but you 
still need to compile with -unittest for other stuff?

I _am_ working on streamlining the unit tests in std.datetime so that they take 
up fewer lines of code without reducing how well they cover the code, so 
depending on your problem with the amount of unit test code, that could help, 
but I expect that whatever your core problem with the number of unit tests is, 
that won't fix it.

- Jonathan M Davis