On 9/2/16 10:26 AM, Ethan Watson wrote:
Can we have a serious discussion in here about the quality of DMD errors?
I've been alternately a dog chasing its own tail, and a dog barking at a
fire hydrant, chasing down errors deep in templated and mixin code over
the last day. This has resulted in manually reducing templates and
mixins by hand until I get to the root of the problem, which then
results in submitting a bug and devising an ugly workaround.
And then I get this one in some code:
Assertion failure: '0' on line 1492 in file 'glue.c'
This is an internal compiler error. It's not a standard way of reporting
errors in D code. It means the internal state of the compiler is messed.
Not much the compiler can do except crash.
The problem ended up being that a symbol tucked away in a template that
itself was tucked away in a template was undefined, but it couldn't tell
me that. Rather, it just assert(0)'d and terminated. Rather less
helpfully, the only meaningful information it could give me at the
assert point (Could it add to it further down the stack? Maybe?) was
defined out because DMD wasn't in a debug build.
What you need to do is submit a bug report with minimal example and tag
as ice. It should have a high priority.
Honestly, I find stuff like this in a compiler unacceptable. Using
assert(0) as shorthand for an unexpected error is all fine and dandy
until you put your product in the hands of the masses and they expect
your program to at least give you some idea of what was going wrong
rather than just crashing out in flames.
So just for fun, I searched DMD for all instances of assert(0) in the
code base.
830 matches in DMD 2.070.2.
That's 830 possible places where the compiler will give the user
virtually no help to track down what (if anything) they did wrong.
But these are sanity checks on the compiler internal state. All the
compiler can do is print that something is wrong and where it detected
that. It can't diagnose the error because that assert is not supposed to
happen!
-Steve
