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'

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.

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.

DMD certainly isn't the only compiler guilty of this. The .NET compiler gives precisely no useful information if it encounters SSE types in C++ headers for example. But compared to MSVC, I've found the error reporting of DMD to be severely lacking. In most cases with MSVC, I have an error code that I can google for which is (sometimes) thoroughly documented. And thanks to being a widely used product, Stack Overflow usually gives me results that I can use in my sleuthing.

I know I'm also seeing more errors than most because I'm doing the kind of code most people don't do. But I'm certainly of the opinion that searching for a compiler error code is far easier than trying to trick google in to matching the text of my error message.

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

On Friday, 2 September 2016 at 14:26:37 UTC, Ethan Watson wrote:
> But compared to MSVC, I've found the error reporting of DMD to be severely lacking. In most cases with MSVC, I have an error code that I can google for which is (sometimes) thoroughly documented.

You're not really comparing DMD to MSVC, are you? ;) Imagine how DMD looked like if there was comparable financial backing...

Anyway, we all know that error reporting can be much improved, but complaining about it doesn't really help (at best, it moves that item up a bit on the mental agenda of some contributors) - getting yourself involved does.

On Friday, 2 September 2016 at 15:12:48 UTC, Steven Schveighoffer wrote:
>
> 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.

On one hand, it's encouraging that he's been using DMD for years and didn't know that.

On the other, though, considering he's been using DMD for years and didn't know that, I think there's a cogent argument for improving even ICE messages.  At the least, have them print "Internal Compiler Error".

Taking it further, maybe actually point out that we'd appreciate this being reported at $URL with an "ice" tag and dustmite'd reduction.  Roll more details into a "So You Found an ICE" wiki tutorial for the people who have (understandably) never done this before (and link it in the error output as well).

-Wyatt

On 09/02/2016 06:45 PM, Wyatt wrote:
> On the other, though, considering he's been using DMD for years and didn't know that, I think there's a cogent argument for improving even ICE messages.  At the least, have them print "Internal Compiler Error".

Great idea, I hacked a quick implementation to make all asserts to direct to bugzilla: https://github.com/dlang/dmd/pull/6103

On Friday, 2 September 2016 at 14:26:37 UTC, 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'
>
> 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.
>
> 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.
>
> DMD certainly isn't the only compiler guilty of this. The .NET compiler gives precisely no useful information if it encounters SSE types in C++ headers for example. But compared to MSVC, I've found the error reporting of DMD to be severely lacking. In most cases with MSVC, I have an error code that I can google for which is (sometimes) thoroughly documented. And thanks to being a widely used product, Stack Overflow usually gives me results that I can use in my sleuthing.
>
> I know I'm also seeing more errors than most because I'm doing the kind of code most people don't do. But I'm certainly of the opinion that searching for a compiler error code is far easier than trying to trick google in to matching the text of my error message.

ICEs like that are always, always compiler bugs. It would be good if it said that in the message and told you to report it...

On Fri, Sep 02, 2016 at 08:43:30PM +0300, Dicebot via Digitalmars-d wrote:
> On 09/02/2016 06:45 PM, Wyatt wrote:
> > On the other, though, considering he's been using DMD for years and didn't know that, I think there's a cogent argument for improving even ICE messages.  At the least, have them print "Internal Compiler Error".
> 
> Great idea, I hacked a quick implementation to make all asserts to direct to bugzilla: https://github.com/dlang/dmd/pull/6103

Very nice. But currently only works with asserts from D code, whereas most of the ICE's I found on bugzilla come from C code (backend or glue layer).

I think it should be possible to "hijack" the C assert() by replacing all instances of #include <assert.h> with something else that redirects the call to a custom function, perhaps one that calls the D assert handler.

(Or, failing that, we can use an IOCCC-style hack of re-#define-ing the assert macro to something else after the fact. Thankfully the C/C++ assert isn't a keyword, so it's easier to hijack. :-P)

There's also util_assert() in backend/util2.c, which can also be
redirected this way.


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan

On 9/2/2016 7:26 AM, Ethan Watson wrote:
> That's 830 possible places where the compiler will give the user virtually no
> help to track down what (if anything) they did wrong.

assert()s are there to check that impossible situations in the compiler don't actually happen. They are not for diagnosing errors in user code.

If a user sees an assert, it is a compiler bug and hopefully he'll submit a bug report for it in bugzilla. There aren't many open assert bugs in bugzilla because we usually put a priority on fixing them.

On Friday, 2 September 2016 at 21:16:02 UTC, Walter Bright wrote:
> assert()s are there to check that impossible situations in the compiler don't actually happen. They are not for diagnosing errors in user code.
>
> If a user sees an assert, it is a compiler bug and hopefully he'll submit a bug report for it in bugzilla. There aren't many open assert bugs in bugzilla because we usually put a priority on fixing them.

You know, I'd love to submit a bug about it. But after actually working out the problem without the compiler's help, I can't get a minimal enough test case to submit a bug with. I'll try it with Dustmite. But in this case, there's debug code there to spit out the information it has. And probably a stack to give it context.

This is legitimately the kind of stuff that drives an average user away from a language. I knew that commenting out one template invocation fixed my code, but not how to fix my template without a bunch of pain-staking removal and experimentation. Call it what you want, but that's a bad user experience.

On 9/2/2016 2:25 PM, Ethan Watson wrote:
> On Friday, 2 September 2016 at 21:16:02 UTC, Walter Bright wrote:
>> assert()s are there to check that impossible situations in the compiler don't
>> actually happen. They are not for diagnosing errors in user code.
>>
>> If a user sees an assert, it is a compiler bug and hopefully he'll submit a
>> bug report for it in bugzilla. There aren't many open assert bugs in bugzilla
>> because we usually put a priority on fixing them.
>
> You know, I'd love to submit a bug about it. But after actually working out the
> problem without the compiler's help, I can't get a minimal enough test case to
> submit a bug with. I'll try it with Dustmite. But in this case, there's debug
> code there to spit out the information it has. And probably a stack to give it
> context.
>
> This is legitimately the kind of stuff that drives an average user away from a
> language. I knew that commenting out one template invocation fixed my code, but
> not how to fix my template without a bunch of pain-staking removal and
> experimentation.

I understand your concern, and that's why we put a priority on fixing asserts that are submitted to bugzilla. But without a bug report, we are completely dead in the water in fixing it. It is supposed to never happen, that is why we cannot fix them in advance.

Using dustmite is a practical way to reduce the source code to a manageable size.

Having a compiler stack trace or it dumping its internal variables is unlikely to help anyone but the compiler devs.


>  Call it what you want, but that's a bad user experience.

Yes it is, which is why we put a priority on fixing them.