Quality of errors in DMD

[Paolo Invernizzi via Digitalmars-d]

David wrote

>In fact, that's precisely what happened to the guys at Weka 
>before, although I'm certain they are not alone with this. They 
>encountered ICEs when updating the compiler version with no way 
>to narrow it down. Of course, *I* could just build DMD with 
>symbols and have a look at what was going on in GDB, but that's 
>the luxury of being a compiler dev.


Walter Bright wrote:

> I do that often. Binary search quickly reduces even the biggest 
> code size. Manually, or using dustmite which works amazingly 
> well.
>
> You can even compile with -v and which will give approximately 
> where in the test case it failed, which makes the initial 
> paring down of source code even faster.
>
>
>> They can create bug reports to help other people to do so, 
>> though.
>
> The bug report I need is the assert location, and a test case 
> that causes it. Users do not need to supply any other 
> information.
>
> I do appreciate, however, when one of our team takes the time 
> to look at such a bug report and makes the effort to narrow 
> things down, and even propose solutions. But this is not 
> expected of users, and the file/line of the assert is 
> self-explanatory to the compiler dev looking at it (at least as 
> self-explanatory as a message like "variable x was not 3 like 
> it was expected to be".)

A good compromise would be to ship a debug version of dmd, with 
most of the printf active, and ship also the log of the 
compilation with the bug report...

/P