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