Quality of errors in DMD

Ethan Watson via Digitalmars-d digitalmars-d at puremagic.com
Sat Sep 3 15:05:33 PDT 2016


On Saturday, 3 September 2016 at 13:20:37 UTC, Adam D. Ruppe 
wrote:
> Except that in the real world, it is an irrelevant distinction 
> because you have stuff to do and can't afford to wait on the 
> compiler team to actually fix the bug.
>
> If nothing else, you'd like to know where it is so you can hack 
> around the bug by changing your implementation. I'm sure every 
> long time D programmer (and likely C++ if you've been in a long 
> time, I have hit many bugs in g++ too) has hit a compiler bug 
> and "fixed" it by using some different approach in their user 
> code.

Exactly this. If a compiler bug stops someone from working in a 
production environment because there's no information about why 
the bug occured, the semantic difference between a compiler bug 
and a user code bug means precisely nothing to the end user. It 
does mean that they're losing hours of work while the problem is 
clumsily attempted to be diagnosed.

In the cases I've been bringing up here, it's all been user code 
that's been the problem *anyway*. Regardless of if the compiler 
author was expecting code to get to that point or not, erroring 
out with zero information is a bad user experience.

This also gets compounded in environments where you can't just 
grab the hottest DMD with a compiler bug fix. Before too long, 
our level builders will be using D as their scripting language. 
They need a stable base. We can't do something like upgrade a 
compiler during a milestone week, so upgrades will be scheduled 
(I'm planning on going with even-numbered releases). A fix for 
the compiler bug is no good if I can't ship it out for months. 
The only way to go there is to implement workarounds until such 
time an upgrade is feasible.

(Side note: There's zero chance of me upgrading to the next DMD 
if it retains the altered allMembers functionality)

These kinds of problems are likely to be compounded when D 
reaches critical mass. It's all well and good to tell people in 
the enthusiast community "Run <x> to get a repro case and make a 
bug". If a problem can't be easily googlable or understandable 
from the error reporting, then that's a turn off for a wider 
audience.


More information about the Digitalmars-d mailing list