www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DustMite, a D test case minimization tool

reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
Inspired by Tigris Delta and the "Want to help DMD bugfixing? Write a  
simple utility" thread from digitalmars.D.learn. I hope the DMD  
development team will find this useful.

Advantages over Tigris delta:

* Easy to use (takes only two arguments, no need to fiddle with levels)
* Readable output (comments and indentation are preserved)
* Native support for multiple files (accepts a path to an entire directory  
for input)
* Written for D
* Written in D
* Not written in Perl
* Can recognize constructs such as try/catch, function invariants  
(in/out/body)
* Only 440 lines of source code

If you've never used delta: this is a tool which attempts to shrink files  
by deleting fragments iteratively, as long as the file satisfies a  
user-specified condition (for example, a specific error message when  
passed through the compiler).

Usage:

1. Formulate a condition command, which should exit with a status code of  
0 when DustMite is on the right track, and anything else otherwise.
    Example: dmd test.d 2>&1 | grep -qF "Assertion failed"
2. Place all the files that dustmite is to minimize in a new directory.
3. If you'd like to test your condition command, don't forget to clean up  
temporary files afterwards.
4. Run: dustmite path/to/directory test-command
5. After a while, dustmite will finish working and create  
path/to/directory.reduced

I've tested it with a self-induced "bug" in std.datetime, it seems to work  
great. If you find that it breaks on something, let me know.

https://github.com/CyberShadow/DustMite

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
May 20 2011
next sibling parent KennyTM~ <kennytm gmail.com> writes:
On May 21, 11 06:01, Vladimir Panteleev wrote:
 Inspired by Tigris Delta and the "Want to help DMD bugfixing? Write a
 simple utility" thread from digitalmars.D.learn. I hope the DMD
 development team will find this useful.

 Advantages over Tigris delta:

 * Easy to use (takes only two arguments, no need to fiddle with levels)
 * Readable output (comments and indentation are preserved)
 * Native support for multiple files (accepts a path to an entire
 directory for input)
 * Written for D
 * Written in D
 * Not written in Perl
 * Can recognize constructs such as try/catch, function invariants
 (in/out/body)
 * Only 440 lines of source code

 If you've never used delta: this is a tool which attempts to shrink
 files by deleting fragments iteratively, as long as the file satisfies a
 user-specified condition (for example, a specific error message when
 passed through the compiler).

 Usage:

 1. Formulate a condition command, which should exit with a status code
 of 0 when DustMite is on the right track, and anything else otherwise.
 Example: dmd test.d 2>&1 | grep -qF "Assertion failed"
 2. Place all the files that dustmite is to minimize in a new directory.
 3. If you'd like to test your condition command, don't forget to clean
 up temporary files afterwards.
 4. Run: dustmite path/to/directory test-command
 5. After a while, dustmite will finish working and create
 path/to/directory.reduced

 I've tested it with a self-induced "bug" in std.datetime, it seems to
 work great. If you find that it breaks on something, let me know.

 https://github.com/CyberShadow/DustMite

Nice tool! I tried to use it to reduce bug 6044, but encountered 2 problems: 1. DustMite will load _all_ files, including the _binary_ ones, which is seldom in valid UTF-8 encoding, and that causes a UtfException to be thrown from 'save.dump' because 'e.header' contains those invalid character. (BTW, Andrei, is it really necessary to include the whole invalid string in the exception?!) 2. For 6044, DustMite has overdone. It has reduced to an obviously invalid program void main() { alias Maybe A; // ok A.Impl!int u; // error } but I guess it can't be avoided, since its error message is exactly the same as the correct one I reported.
May 22 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 22 May 2011 11:56:33 +0300, KennyTM~ <kennytm gmail.com> wrote:

 Nice tool! I tried to use it to reduce bug 6044, but encountered 2  
 problems:

 1. DustMite will load _all_ files, including the _binary_ ones, which
     is seldom in valid UTF-8 encoding, and that causes a UtfException to
     be thrown from 'save.dump' because 'e.header' contains those invalid
     character. (BTW, Andrei, is it really necessary to include the whole
     invalid string in the exception?!)

The real question here is why would appender validate UTF when appending a string to a string? This reduces the complexity of whatever a GC allocation COULD be to linear, so for large strings it might be slower than appending to an array. The following comment is in Phobos, but I don't understand it: // note, we disable this branch for appending one type of char to // another because we can't trust the length portion. The tool should have been able to handle binary files (it only attempts to reduce them by completely removing them), but I never tested this functionality. Anyway, I've made it use ubyte[] for the appender type, so there won't be any problems now.
 2. For 6044, DustMite has overdone. It has reduced to an obviously
     invalid program

        void main() {
            alias Maybe A;
        // ok
            A.Impl!int u;       // error
        }

     but I guess it can't be avoided, since its error message is exactly
     the same as the correct one I reported.

DustMite is only as smart as the test command you specify. You could formulate your test command to check if the source code still includes whatever bits should not be removed. Generally, though, DustMite is most useful for reducing large programs you don't want to reduce by hand, but especially when the error message is cryptic, makes no indication of the real location (such as some templated functions in Phobos), or is so fragile that removing seemingly unrelated code makes the problem vanish. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
May 22 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 22 May 2011 09:40:19 -0400, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

 On Sun, 22 May 2011 11:56:33 +0300, KennyTM~ <kennytm gmail.com> wrote:

 Nice tool! I tried to use it to reduce bug 6044, but encountered 2  
 problems:

 1. DustMite will load _all_ files, including the _binary_ ones, which
     is seldom in valid UTF-8 encoding, and that causes a UtfException to
     be thrown from 'save.dump' because 'e.header' contains those invalid
     character. (BTW, Andrei, is it really necessary to include the whole
     invalid string in the exception?!)

The real question here is why would appender validate UTF when appending a string to a string? This reduces the complexity of whatever a GC allocation COULD be to linear, so for large strings it might be slower than appending to an array. The following comment is in Phobos, but I don't understand it: // note, we disable this branch for appending one type of char to // another because we can't trust the length portion.

Essentially, this comment is about how you have to decode and then encode anytime one changes the character type. i.e. the fact that 1 dchar != 1 wchar != 1 char. So a 5 dchar string, might require 20 chars to represent. As for performance, using appender is never slower than ~=, as it uses essentially the same code. Furthermore, you actually can not make appender use linear allocation, even when you are doing a transcoding operation, as it always grows by max(needed, newCapacity() ), which gives it a roughly an exponential growth rate. Also, if you're concerned about appender performance, I'd recommend using the patch from Issue 5813.
May 22 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Mon, 23 May 2011 02:15:49 +0300, Robert Jacques <sandford jhu.edu>  
wrote:

  As for performance, using appender is never slower than ~=, as it uses  
 essentially the same code.

I don't think using ~= when appending a string to a string will validate the UTF. Will it? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
May 22 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 22 May 2011 19:30:58 -0400, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

 On Mon, 23 May 2011 02:15:49 +0300, Robert Jacques <sandford jhu.edu>  
 wrote:

  As for performance, using appender is never slower than ~=, as it uses  
 essentially the same code.

I don't think using ~= when appending a string to a string will validate the UTF. Will it?

For string ~= string, appender calls string[] = string, which does a memcopy, iirc.
May 22 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Mon, 23 May 2011 04:14:32 +0300, Robert Jacques <sandford jhu.edu>  
wrote:

 On Sun, 22 May 2011 19:30:58 -0400, Vladimir Panteleev  
 <vladimir thecybershadow.net> wrote:

 On Mon, 23 May 2011 02:15:49 +0300, Robert Jacques <sandford jhu.edu>  
 wrote:

  As for performance, using appender is never slower than ~=, as it  
 uses essentially the same code.

I don't think using ~= when appending a string to a string will validate the UTF. Will it?

For string ~= string, appender calls string[] = string, which does a memcopy, iirc.

Right, so my complexity rant was BS, but appender will still validate UTF on every append, unlike ~=. Isn't that a bug? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
May 22 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 22 May 2011 21:39:55 -0400, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:
 On Mon, 23 May 2011 04:14:32 +0300, Robert Jacques <sandford jhu.edu>  
 wrote:

 On Sun, 22 May 2011 19:30:58 -0400, Vladimir Panteleev  
 <vladimir thecybershadow.net> wrote:

 On Mon, 23 May 2011 02:15:49 +0300, Robert Jacques <sandford jhu.edu>  
 wrote:

  As for performance, using appender is never slower than ~=, as it  
 uses essentially the same code.

I don't think using ~= when appending a string to a string will validate the UTF. Will it?

For string ~= string, appender calls string[] = string, which does a memcopy, iirc.

Right, so my complexity rant was BS, but appender will still validate UTF on every append, unlike ~=. Isn't that a bug?

Appender doesn't validate UTF when the character widths are the same. For example, string test = "\&lt;" ~ "\&gt;" ~ "\&Alpha;" ~ "\&Beta;" ~ "\&Gamma;"~ "\&spades;" ~ "\&diams;"~ "\U0001D11E"; Appender!string app; foreach(i;0..ds.length-1) { app.put(test[i..$]); } Runs fine, even though at times test[i..$] is an invalid string, because the type of test and appender are both strings. However, if you change Appender to a wstring, then encoding and decoding occur and those routines always validate. Hence, if app is a Appender!wstring, it will throw a UTF validation error.
May 22 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Mon, 23 May 2011 05:21:04 +0300, Robert Jacques <sandford jhu.edu>  
wrote:

 Appender doesn't validate UTF when the character widths are the same.

Yes it does. That's what I've been trying to explain this entire subthread. import std.array; void main() { string invalid = "\xAA\xBB\xCC\xDD\xEE\xFF"; string str; str ~= invalid; // OK auto app = appender!string(); app.put(str); // throws } -- Best regards, Vladimir mailto:vladimir thecybershadow.net
May 22 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 22 May 2011 22:31:51 -0400, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

 On Mon, 23 May 2011 05:21:04 +0300, Robert Jacques <sandford jhu.edu>  
 wrote:

 Appender doesn't validate UTF when the character widths are the same.

Yes it does. That's what I've been trying to explain this entire subthread. import std.array; void main() { string invalid = "\xAA\xBB\xCC\xDD\xEE\xFF"; string str; str ~= invalid; // OK auto app = appender!string(); app.put(str); // throws }

Well, all I can say is that it doesn't throw on my install. (Windows, DMD 2.052) for either the patched nor un-patched appender implementation. What version are you using?
May 22 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Mon, 23 May 2011 07:41:22 +0300, Robert Jacques <sandford jhu.edu>  
wrote:

 Well, all I can say is that it doesn't throw on my install. (Windows,  
 DMD 2.052) for either the patched nor un-patched appender  
 implementation. What version are you using?

2.053. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
May 22 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Mon, 23 May 2011 00:48:07 -0400, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

 On Mon, 23 May 2011 07:41:22 +0300, Robert Jacques <sandford jhu.edu>  
 wrote:

 Well, all I can say is that it doesn't throw on my install. (Windows,  
 DMD 2.052) for either the patched nor un-patched appender  
 implementation. What version are you using?

2.053.

Ah. I think I've tracked down the problem. The term is(Range == Unqual!(T)[]) used to be true for a string and char[], and now it's properly being evaluated to false, which in turn causes the wrong static if branch to compile. So yes, this is a regression bug. You can fix by replacing the conditional (at line 1594) with: // note, we disable this branch for appending one type of char to // another because we can't trust the length portion. static if (is(typeof(_data.arr[0..1] = items[0..1])) && is(typeof(items.length) == size_t)) Or you can try out my patch to appender: http://d.puremagic.com/issues/show_bug.cgi?id=5813
May 22 2011
prev sibling next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
This seems very cool. It's churning away at a DMD64 bug that's manifested 
in SDC. If it produces something usable, I'll be very impressed.

(I'm really only posting to see my name on the IRC DSpamBot :P)
May 22 2011
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 20/05/2011 23:01, Vladimir Panteleev wrote:
 Inspired by Tigris Delta and the "Want to help DMD bugfixing? Write a
 simple utility" thread from digitalmars.D.learn. I hope the DMD
 development team will find this useful.

 Advantages over Tigris delta:

 * Easy to use (takes only two arguments, no need to fiddle with levels)
 * Readable output (comments and indentation are preserved)
 * Native support for multiple files (accepts a path to an entire
 directory for input)
 * Written for D
 * Written in D
 * Not written in Perl
 * Can recognize constructs such as try/catch, function invariants
 (in/out/body)
 * Only 440 lines of source code

 If you've never used delta: this is a tool which attempts to shrink
 files by deleting fragments iteratively, as long as the file satisfies a
 user-specified condition (for example, a specific error message when
 passed through the compiler).

 Usage:

 1. Formulate a condition command, which should exit with a status code
 of 0 when DustMite is on the right track, and anything else otherwise.
 Example: dmd test.d 2>&1 | grep -qF "Assertion failed"
 2. Place all the files that dustmite is to minimize in a new directory.
 3. If you'd like to test your condition command, don't forget to clean
 up temporary files afterwards.
 4. Run: dustmite path/to/directory test-command
 5. After a while, dustmite will finish working and create
 path/to/directory.reduced

 I've tested it with a self-induced "bug" in std.datetime, it seems to
 work great. If you find that it breaks on something, let me know.

 https://github.com/CyberShadow/DustMite

Just attempted to use it, I get the following when trying to compile: $ dmd -O -release -inline dustmite.d dsplit.d dsplit.d(245): Error: undefined identifier module dsplit.replaceInPlace dsplit.d(253): Error: undefined identifier module dsplit.replaceInPlace dsplit.d(259): Error: undefined identifier module dsplit.replaceInPlace With git revision 0699cca148a59beb4d4def44bea0e7b49f558d58. -- Robert http://octarineparrot.com/
May 23 2011
parent Robert Clipsham <robert octarineparrot.com> writes:
On 23/05/2011 20:50, Vladimir Panteleev wrote:
 On Mon, 23 May 2011 22:48:52 +0300, Robert Clipsham
 <robert octarineparrot.com> wrote:

 Just attempted to use it, I get the following when trying to compile:

 $ dmd -O -release -inline dustmite.d dsplit.d
 dsplit.d(245): Error: undefined identifier module dsplit.replaceInPlace
 dsplit.d(253): Error: undefined identifier module dsplit.replaceInPlace
 dsplit.d(259): Error: undefined identifier module dsplit.replaceInPlace

 With git revision 0699cca148a59beb4d4def44bea0e7b49f558d58.

Please update your compiler and standard library?

Ah, that sorted it, thanks. -- Robert http://octarineparrot.com/
May 23 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Mon, 23 May 2011 22:48:52 +0300, Robert Clipsham  
<robert octarineparrot.com> wrote:

 Just attempted to use it, I get the following when trying to compile:

 $ dmd -O -release -inline dustmite.d dsplit.d
 dsplit.d(245): Error: undefined identifier module dsplit.replaceInPlace
 dsplit.d(253): Error: undefined identifier module dsplit.replaceInPlace
 dsplit.d(259): Error: undefined identifier module dsplit.replaceInPlace

 With git revision 0699cca148a59beb4d4def44bea0e7b49f558d58.

Please update your compiler and standard library? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
May 23 2011
prev sibling next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 20/05/2011 23:01, Vladimir Panteleev wrote:
 I've tested it with a self-induced "bug" in std.datetime, it seems to
 work great. If you find that it breaks on something, let me know.

Wow, this tool works fantastically! Narrowed down a 5000 line test case to about 80 lines (I've managed to get it down to 26 lines by removing comments/make semantic changes there's no way it would be able to do without some sort of semantic analysis). I'd note that the code wasn't the most simple either, involving templates, mixins, ctfe, objects, etc. A couple of notes that we've already discussed, but I'll paste here for others: * The tool spent about 10 minutes figuring out if it was ok to delete files in .git, then deleting them - this pretty much doubled the time taken to run the tool! * It took me a while to figure out, the test command is run from the directory you pass on the command line. You also score bonus points for being far simpler to set up than delta, and working *a lot* better than it (for D at least, I haven't tried it with anything else). Well done. -- Robert http://octarineparrot.com/
May 23 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 24 May 2011 00:04:39 +0300, Robert Clipsham  
<robert octarineparrot.com> wrote:

 On 20/05/2011 23:01, Vladimir Panteleev wrote:
 I've tested it with a self-induced "bug" in std.datetime, it seems to
 work great. If you find that it breaks on something, let me know.

Wow, this tool works fantastically! Narrowed down a 5000 line test case to about 80 lines (I've managed to get it down to 26 lines by removing comments/make semantic changes there's no way it would be able to do without some sort of semantic analysis). I'd note that the code wasn't the most simple either, involving templates, mixins, ctfe, objects, etc. A couple of notes that we've already discussed, but I'll paste here for others: * The tool spent about 10 minutes figuring out if it was ok to delete files in .git, then deleting them - this pretty much doubled the time taken to run the tool! * It took me a while to figure out, the test command is run from the directory you pass on the command line. You also score bonus points for being far simpler to set up than delta, and working *a lot* better than it (for D at least, I haven't tried it with anything else). Well done.

Thanks! I've improved it based on your and others' feedback, and wrote some documentation: https://github.com/CyberShadow/DustMite/wiki -- Best regards, Vladimir mailto:vladimir thecybershadow.net
May 24 2011
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Vladimir Panteleev wrote:
 Inspired by Tigris Delta and the "Want to help DMD bugfixing? Write a 
 simple utility" thread from digitalmars.D.learn. I hope the DMD 
 development team will find this useful.
 
 Advantages over Tigris delta:
 
 * Easy to use (takes only two arguments, no need to fiddle with levels)
 * Readable output (comments and indentation are preserved)
 * Native support for multiple files (accepts a path to an entire 
 directory for input)
 * Written for D
 * Written in D
 * Not written in Perl
 * Can recognize constructs such as try/catch, function invariants 
 (in/out/body)
 * Only 440 lines of source code
 
 If you've never used delta: this is a tool which attempts to shrink 
 files by deleting fragments iteratively, as long as the file satisfies a 
 user-specified condition (for example, a specific error message when 
 passed through the compiler).
 
 Usage:
 
 1. Formulate a condition command, which should exit with a status code 
 of 0 when DustMite is on the right track, and anything else otherwise.
    Example: dmd test.d 2>&1 | grep -qF "Assertion failed"
 2. Place all the files that dustmite is to minimize in a new directory.
 3. If you'd like to test your condition command, don't forget to clean 
 up temporary files afterwards.
 4. Run: dustmite path/to/directory test-command
 5. After a while, dustmite will finish working and create 
 path/to/directory.reduced
 
 I've tested it with a self-induced "bug" in std.datetime, it seems to 
 work great. If you find that it breaks on something, let me know.
 
 https://github.com/CyberShadow/DustMite
 

This is fantastic for ICE bugs. But it doesn't work well for certain types of bugs, such as the one I tracked down recently, which are of the form: assert(foo()==30); int foo() { if (func1()) return 0; return func2(); } It reduces foo() to: int foo() { return 0; } which causes the test to still fail, but the bug is gone. The --noremove option doesn't help much because you have to name all of the functions which have that behaviour, and you don't know them in advance. I was pretty surprised to find that reduced test cases still had comments in them. They should be the first things to be stripped out. ---- Something which has occured to me is that nearly always when I'm reducing a bug, the code which is actually getting run is close to minimal. So running with -cov and then removing any line with 0000 hits would probably be pretty effective. Of course, you need to make sure it still compiles, which could be quite difficult. You could run -cov in the first run, and then when you slice up the file, you could mark sections as 'hit' (count>0), 'missed'(count==0), or 'void' (no count, could be a declaration, or a comment). Generally any section with a 'hit' shouldn't be removed, but the test case isn't minimal until all 'missed' lines are gone. Most of the 'void' lines are probably removable too (it just won't compile, if they are necessary).
May 25 2011
parent Don <nospam nospam.com> writes:
Don wrote:
 Vladimir Panteleev wrote:
 Inspired by Tigris Delta and the "Want to help DMD bugfixing? Write a 
 simple utility" thread from digitalmars.D.learn. I hope the DMD 
 development team will find this useful.

 Advantages over Tigris delta:

 * Easy to use (takes only two arguments, no need to fiddle with levels)
 * Readable output (comments and indentation are preserved)
 * Native support for multiple files (accepts a path to an entire 
 directory for input)
 * Written for D
 * Written in D
 * Not written in Perl
 * Can recognize constructs such as try/catch, function invariants 
 (in/out/body)
 * Only 440 lines of source code

 If you've never used delta: this is a tool which attempts to shrink 
 files by deleting fragments iteratively, as long as the file satisfies 
 a user-specified condition (for example, a specific error message when 
 passed through the compiler).

 Usage:

 1. Formulate a condition command, which should exit with a status code 
 of 0 when DustMite is on the right track, and anything else otherwise.
    Example: dmd test.d 2>&1 | grep -qF "Assertion failed"
 2. Place all the files that dustmite is to minimize in a new directory.
 3. If you'd like to test your condition command, don't forget to clean 
 up temporary files afterwards.
 4. Run: dustmite path/to/directory test-command
 5. After a while, dustmite will finish working and create 
 path/to/directory.reduced

 I've tested it with a self-induced "bug" in std.datetime, it seems to 
 work great. If you find that it breaks on something, let me know.

 https://github.com/CyberShadow/DustMite

This is fantastic for ICE bugs. But it doesn't work well for certain types of bugs, such as the one I tracked down recently, which are of the form: assert(foo()==30); int foo() { if (func1()) return 0; return func2(); } It reduces foo() to: int foo() { return 0; } which causes the test to still fail, but the bug is gone. The --noremove option doesn't help much because you have to name all of the functions which have that behaviour, and you don't know them in advance. I was pretty surprised to find that reduced test cases still had comments in them. They should be the first things to be stripped out. ---- Something which has occured to me is that nearly always when I'm reducing a bug, the code which is actually getting run is close to minimal. So running with -cov and then removing any line with 0000 hits would probably be pretty effective. Of course, you need to make sure it still compiles, which could be quite difficult. You could run -cov in the first run, and then when you slice up the file, you could mark sections as 'hit' (count>0), 'missed'(count==0), or 'void' (no count, could be a declaration, or a comment). Generally any section with a 'hit' shouldn't be removed, but the test case isn't minimal until all 'missed' lines are gone. Most of the 'void' lines are probably removable too (it just won't compile, if they are necessary).

Specific suggestion: When dustmite does the initial slicing of the file, it should look for a matching .lst file. If it exists, then for any line in the .lst file where there is a '1'..'9' before the first non-numeric character on that line, that corresponding line in the .d file should be ineligible for deletion. (This is recursive; the function it's in shouldn't be deletable in its entirity). Everything else should be unchanged. Then, for these unstable bugs, the user just needs to compile with -cov first, and retain the .lst files in the directory.
May 25 2011
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 26 May 2011 09:58:33 +0300, Don <nospam nospam.com> wrote:

  This is fantastic for ICE bugs. But it doesn't work well for certain  
 types of bugs, such as the one I tracked down recently, which are of  
 the form:


I've improved DustMite with your suggestions, and added the --strip-comments and --coverage options. The algorithm itself has been substantially improved as well. As an example, I tried to reduce rdmd to see why it didn't compile with latest DMD/Phobos (with an unhelpful error message pointing inside std.array). Old version: https://gist.github.com/994106 New version: https://gist.github.com/994108 The first and last imports couldn't be reduced, but it's still a great improvement. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
May 27 2011