www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Quality of errors in DMD

reply Ethan Watson <gooberman gmail.com> writes:
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.
Sep 02 2016
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 02 2016
parent reply Wyatt <wyatt.epp gmail.com> writes:
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
Sep 02 2016
parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D
Subject: Re: Quality of errors in DMD
References: <qkxyfiwjwqklftcwtcik forum.dlang.org>
 <nqc4tg$12im$1 digitalmars.com> <zhfoosuvzytytlfjhyal forum.dlang.org>
In-Reply-To: <zhfoosuvzytytlfjhyal forum.dlang.org>

--AoBtIe3JlwM68txwvvciH644WdWmuE4kc
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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


--AoBtIe3JlwM68txwvvciH644WdWmuE4kc--
Sep 02 2016
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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
Sep 02 2016
prev sibling next sibling parent kink <noone nowhere.com> writes:
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.
Sep 02 2016
prev sibling next sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
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...
Sep 02 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 02 2016
next sibling parent reply Ethan Watson <gooberman gmail.com> writes:
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.
Sep 02 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 02 2016
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 02, 2016 at 02:52:57PM -0700, Walter Bright via Digitalmars-d wrote:
[...]

 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.


What *would* help greatly is if, upon encountering an unexpected
problem, the compiler told the user something to the effect of "hey
there, I'm really sorry but apparently I've run into a problem I don't
know how to solve; could you please file a bug report at $URL so that
the compiler authors look into the problem?"  Instead of blurting out
something in encrypted Klingon that nobody understands, like
"backend/gjqzx.c 12345 phlebotinum overload".

OK, I exaggerate, but seriously, to anyone unfamiliar with compiler
internals, dmd asserts might as well be talking about phlebotinum
overloads and they couldn't tell the difference.  If the error message
isn't being helpful, the chances of a bug report being filed are pretty
low, which means the chances of the problem getting fixed is even lower.

I think this PR would go a long way at making dmd friendlier to new D
users, if we can figure out how to make it work for all asserts
including from C code:

	https://github.com/dlang/dmd/pull/6103



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


A user wouldn't even know what dustmite is, let alone that it exists and
is applicable to this situation, or where to find it and how to use it,
unless they were told. Preferably by the compiler before it terminates
with an assert error. ;-)



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


[...]

Stack traces or internal variable dumps are equally unhelpful as the
current phlebotinum overload abort messages.  What we need is for the
compiler to tell the user (1) this is a compiler bug, not some fault in
their own code; (2) where to report this bug so that there's actually a
chance the problem will get fixed; (3) what is dustmite, where to find
it, and how it would help in formulating a bug report. And optionally,
(4) where to go to ask for help if you really need to find some way to
work around a compiler bug and get your code working again (e.g.,
forum.dlang.org).

If I were to run some random program downloaded off the 'net and it came
back to me with:

	phlebo/tinum.c 12345 zyxqwqyb error

with no information about (1), (2), or (3), chances are pretty high that
I would just delete the program and move on to something else. I
wouldn't bother spending the effort to find out where to file bug
reports, and the problem will likely go unfixed and it will continue to
turn off yet more would-be users.

We need to get PR 6103 off the ground.


T

-- 
Let's eat some disquits while we format the biskettes.
Sep 02 2016
prev sibling parent reply Ethan Watson <gooberman gmail.com> writes:
On Friday, 2 September 2016 at 21:52:57 UTC, Walter Bright wrote:

 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.


We have a rule in our codebase, and it's been the same in every 
codebase I've worked in professionally. If you throw an assert, 
you have to give a reason and useful information in the assert.

Thus, an error in code that looks like:

assert(0);

Makes no sense to me when in this case it could have been:

fatal_error("Invalid type (from %d to %s)", tx->ty, 
tx->toChars());

The quality of error reporting has immediately increased. And it 
would require the creation of a fatal_error macro that does an 
assert. But now I'm not scratching my head wondering what went 
wrong in the compiler.

Browsing through that function, I can also see another assert 
that doesn't let you use vector types unless you're running a 
64-bit build or are on OSX. It doesn't tell me that through an 
error message. I had to look at the source code to work it out. 
fatal_error("Vector types unavailable on the target platform"); 
and someone's day was made better. And then a couple of lines 
above that, another assert(0). fatal_error("Invalid vector type 
%s", tx->toChars()); and someone can deal with the unexpected.

If I have to open up the compiler's source to get an idea of what 
I'm doing wrong, that's a bad user experience. And why I want a 
discussion about this. Not to whinge, not to get a bug fix. But 
to highlight that assert(0) is a bad pattern and there should be 
a discussion about changing the usage of asserts inside DMD.
Sep 03 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/3/2016 3:57 AM, Ethan Watson wrote:

 Browsing through that function, I can also see another assert that doesn't let
 you use vector types unless you're running a 64-bit build or are on OSX. It
 doesn't tell me that through an error message. I had to look at the source code
 to work it out. fatal_error("Vector types unavailable on the target platform");
 and someone's day was made better. And then a couple of lines above that,
 another assert(0). fatal_error("Invalid vector type %s", tx->toChars()); and
 someone can deal with the unexpected.


This appears to conflate diagnosing errors in the user's source code with 
detecting bugs in the compiler. A user source code error should have been 
diagnosed long before those asserts are hit (and if not, it's a compiler bug,
by 
definition, not a user source code problem).



 If I have to open up the compiler's source to get an idea of what I'm doing
 wrong, that's a bad user experience. And why I want a discussion about this.
Not
 to whinge, not to get a bug fix. But to highlight that assert(0) is a bad
 pattern and there should be a discussion about changing the usage of asserts
 inside DMD.


Except that asserts are checking for compiler bugs, not diagnostics on user 
code. I don't expect users to debug the compiler - if they get an assert they 
should file a bug report to bugzilla and let us debug the compiler and fix it.

----

Aside: we regularly have threads here where the difference between detecting 
programming bugs and detecting input errors is discussed. I fear another one is 
gathering steam, and if so, I'll likely not participate in it.
Sep 03 2016
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-09-03 14:12, Walter Bright wrote:


 Except that asserts are checking for compiler bugs, not diagnostics on
 user code. I don't expect users to debug the compiler - if they get an
 assert they should file a bug report to bugzilla and let us debug the
 compiler and fix it.


What kind of issue due you see with trying to print some form of 
information when an assertion fails? I would have certainty help me the 
times I've hacked on the compiler and triggered an assertion. Why 
shouldn't the developers working on the compiler getting as much help as 
possible?

-- 
/Jacob Carlborg
Sep 03 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/3/2016 6:14 AM, Jacob Carlborg wrote:

 What kind of issue due you see with trying to print some form of information
 when an assertion fails?


Because it's useless to anyone but the compiler devs, and it adds cruft to the 
compiler. And even worse than useless, it confuses the user into thinking it is 
a meaningful message.

It is not. It is a compiler bug. It has meaning only to the compiler developer, 
and hence does not belong in the *user* interface. Let's not pretend the user 
can debug the compiler.



 I would have certainty help me the times I've hacked on
 the compiler and triggered an assertion. Why shouldn't the developers working
on
 the compiler getting as much help as possible?


The compiler code is littered with helpful debugging printf's that are
commented 
out. I use them all the time. There is no purpose to them if one is not
actively 
working on the compiler.
Sep 03 2016
next sibling parent reply Shachar Shemesh <shachar weka.io> writes:
On 04/09/16 01:39, Walter Bright wrote:

 On 9/3/2016 6:14 AM, Jacob Carlborg wrote:

 What kind of issue due you see with trying to print some form of
 information
 when an assertion fails?


 Because it's useless to anyone but the compiler devs, and it adds cruft
 to the compiler. And even worse than useless, it confuses the user into
 thinking it is a meaningful message.


assert(0, "Compiler bug: symbol table should have been initialized by 
this point");

This confuses the user less than the current situation, and at the same 
time give people who are genuinely trying to have the compiler something 
to work on to understand why the assert is there.

Speaking for my own, the RAID team in Weka started a rule saying not to 
allow asserts with no strings in our code. Every assert should have a 
message, preferably with parameters, giving some hint regarding what 
went wrong and what the expected values should have been. It's a pain to 
write them, but it more than pays off when they get actually triggered.

We just found out that having just the assert, even when the condition 
makes it clear, even when there is a comment next to it explaining it, 
is just too confusing. More often than you think, it also involves 
cursing yourself for not having the value of one variable or another 
(and, no, the cores are, more often than not, useless. I'm not sure why).

I understand you don't see the need, but I'd like you to consider the 
possibility that having more people able to hack the front end is also 
something that would help to give D a boost. If the cost of becoming a 
compiler developer was lower, wouldn't things progress more rapidly?

Shachar
Sep 04 2016
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 05/09/2016 2:19 AM, Shachar Shemesh wrote:

 I understand you don't see the need, but I'd like you to consider the
 possibility that having more people able to hack the front end is also
 something that would help to give D a boost. If the cost of becoming a
 compiler developer was lower, wouldn't things progress more rapidly?

 Shachar


Ironically the assert that triggered this entire conversation was in the 
glue layer of dmd, where by a switch statement didn't know how to handle 
something being pushed to it.
Sep 04 2016
prev sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Saturday, 3 September 2016 at 22:39:22 UTC, Walter Bright 
wrote:

 Because it's useless to anyone but the compiler devs, and it 
 adds cruft to the compiler. And even worse than useless, it 
 confuses the user into thinking it is a meaningful message.


This is short-sighted, for the reason I pointed out in my earlier 
post. How would you go about reporting an ICE for a 100k LOC test 
case without any idea about where to start looking?

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.


 Let's not pretend the user can debug the compiler.


They can create bug reports to help other people to do so, though.

  — David
Sep 04 2016
next sibling parent Nemanja Boric <4burgos gmail.com> writes:
On Sunday, 4 September 2016 at 17:56:08 UTC, David Nadlinger 
wrote:

 On Saturday, 3 September 2016 at 22:39:22 UTC, Walter Bright 
 wrote:

 Because it's useless to anyone but the compiler devs, and it 
 adds cruft to the compiler. And even worse than useless, it 
 confuses the user into thinking it is a meaningful message.


 This is short-sighted, for the reason I pointed out in my 
 earlier post. How would you go about reporting an ICE for a 
 100k LOC test case without any idea about where to start 
 looking?

 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.


 Let's not pretend the user can debug the compiler.


 They can create bug reports to help other people to do so, 
 though.

  — David


I second this - sometimes you find it way too late: We had a 
nasty problem few weeks ago where *only compiling with `-O`*
kept crashing a compiler on a assertion 
(https://issues.dlang.org/show_bug.cgi?id=16225). And it was 
several thousands lines worth of code spread across many modules.

What I find useful is enabling debug prints of dmd, compiling and 
first concentration on the last mentioned module (I don't 
remember if this was already there, or if I extended some 
`writeln/printf`there). Then I approached it in the usual way - 
binary removing/putting back chunks of code.
Sep 04 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/4/2016 10:56 AM, David Nadlinger wrote:

 This is short-sighted, for the reason I pointed out in my earlier post. How
 would you go about reporting an ICE for a 100k LOC test case without any idea
 about where to start looking?


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".)
Sep 04 2016
next sibling parent Paolo Invernizzi <paolo.invernizzi no.address> writes:
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
Sep 05 2016
prev sibling next sibling parent reply Dominikus Dittes Scherkl <Dominikus.Scherkl continental-corporation.com> writes:
On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright wrote:

 On 9/4/2016 10:56 AM, David Nadlinger wrote:
 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.


So, if we assume the user cannot debug if he hit an compiler bug, 
I as a compiler developer would at least like to receive a report 
containing a simple number, to identify which of the 830 
assert(0)'s in the code that I deemed to be unreachable was 
actually hit.

Because even if I don't receive a reduced testcase, I have a 
strong hint what assumption I should re-think, now that I know 
that it is effectively NOT unreachable.

Could we agree so far?

SO what problem would it be to give the assert(0)'s a number each 
and print out a message:
"Compiler bug: assert #xxx was hit, please send a bug report"
?
Sep 05 2016
parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Monday, 5 September 2016 at 15:55:16 UTC, Dominikus Dittes 
Scherkl wrote:

 On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright 
 wrote:

 On 9/4/2016 10:56 AM, David Nadlinger wrote:
 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.


 So, if we assume the user cannot debug if he hit an compiler 
 bug, I as a compiler developer would at least like to receive a 
 report containing a simple number, to identify which of the 830 
 assert(0)'s in the code that I deemed to be unreachable was 
 actually hit.

 Because even if I don't receive a reduced testcase, I have a 
 strong hint what assumption I should re-think, now that I know 
 that it is effectively NOT unreachable.

 Could we agree so far?

 SO what problem would it be to give the assert(0)'s a number 
 each and print out a message:
 "Compiler bug: assert #xxx was hit, please send a bug report"
 ?


I wonder what people think of opt in automatic statistic 
collecting.  Not a substitute for a bug report, as one doesn't 
want source code being shipped off, but suppose a central server 
at dlang.org tracks internal compiler errors for those who have 
opted in. At least it will be more obvious more quickly which 
parts of code seem to be asserting.
Sep 06 2016
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright wrote:

 On 9/4/2016 10:56 AM, David Nadlinger wrote:

 This is short-sighted, for the reason I pointed out in my 
 earlier post. How
 would you go about reporting an ICE for a 100k LOC test case 
 without any idea
 about where to start looking?


 I do that often. Binary search quickly reduces even the biggest 
 code size. Manually, or using dustmite which works amazingly 
 well.


That is not true. I had dustmite runs that lasted days (!) to 
report some ICE in my code.
Sep 05 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 6 September 2016 at 05:43:55 UTC, deadalnix wrote:

 On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright 
 wrote:

 I do that often. Binary search quickly reduces even the 
 biggest code size. Manually, or using dustmite which works 
 amazingly well.


 That is not true. I had dustmite runs that lasted days (!) to 
 report some ICE in my code.


I know it's tempting, but the idea is to NOT stare at the screen 
watching DustMite run, and go do something else instead :)

If you have more cores than time, DustMite now has -j.
Sep 05 2016
parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 6 September 2016 at 05:46:51 UTC, Vladimir Panteleev 
wrote:

 On Tuesday, 6 September 2016 at 05:43:55 UTC, deadalnix wrote:

 On Sunday, 4 September 2016 at 20:14:37 UTC, Walter Bright 
 wrote:

 I do that often. Binary search quickly reduces even the 
 biggest code size. Manually, or using dustmite which works 
 amazingly well.


 That is not true. I had dustmite runs that lasted days (!) to 
 report some ICE in my code.


 I know it's tempting, but the idea is to NOT stare at the 
 screen watching DustMite run, and go do something else instead 
 :)

 If you have more cores than time, DustMite now has -j.


That's what I did. Launched it on a server and waited for it to 
finish.
Sep 05 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 3 September 2016 at 12:12:34 UTC, Walter Bright 
wrote:

 Except that asserts are checking for compiler bugs, not 
 diagnostics on user code.


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.


I understand if you want to say producing better error messages 
in the compiler is a pain and you have other priorities, but 
surely you accept that they are valuable for this reason if 
nothing else.
Sep 03 2016
next sibling parent reply Ethan Watson <gooberman gmail.com> writes:
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.
Sep 03 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/3/2016 3:05 PM, Ethan Watson wrote:

 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.


Nobody is suggesting that asserts are a good user experience. I've asserted (!) 
over and over that this is why asserts have a high priority to get fixed.

Adding more text to the assert message is not helpful to end users.
Sep 03 2016
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 3 September 2016 at 22:53:25 UTC, Walter Bright 
wrote:

 On 9/3/2016 3:05 PM, Ethan Watson wrote:

 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.


 Nobody is suggesting that asserts are a good user experience. 
 I've asserted (!) over and over that this is why asserts have a 
 high priority to get fixed.

 Adding more text to the assert message is not helpful to end 
 users.


Perhaps the best error message would be "Please post this as a 
bug to bugzilla."
Sep 03 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/3/2016 5:09 PM, Stefan Koch wrote:

 Perhaps the best error message would be "Please post this as a bug to
bugzilla."


That's fine with me, and Dicebot made a PR to do it.
Sep 03 2016
prev sibling parent Ethan Watson <gooberman gmail.com> writes:
On Sunday, 4 September 2016 at 00:09:50 UTC, Stefan Koch wrote:

 Perhaps the best error message would be "Please post this as a 
 bug to bugzilla."


I'd say that's in addition to getting rid of assert(0), not 
instead of.
Sep 04 2016
prev sibling parent Ethan Watson <gooberman gmail.com> writes:
On Saturday, 3 September 2016 at 22:53:25 UTC, Walter Bright 
wrote:

 Adding more text to the assert message is not helpful to end 
 users.


Really? I've highlighted several cases just in this one function 
in glue.c that would have saved me hours of time.
Sep 04 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/3/2016 6:20 AM, Adam D. Ruppe wrote:

 On Saturday, 3 September 2016 at 12:12:34 UTC, Walter Bright wrote:

 Except that asserts are checking for compiler bugs, not diagnostics on user
code.


 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.


Users are not equipped to do that, and we shouldn't raise false expectations 
that they can. Developers who are equipped to that are able and willing to
build 
the compiler from source with debugging turned on.

Really, what possible use is there to an end user for an assert that
unhelpfully 
printed out a message that the register allocator failed? There's nothing "user 
friendly" about a such a message.



 I understand if you want to say producing better error messages in the compiler
 is a pain and you have other priorities, but surely you accept that they are
 valuable for this reason if nothing else.


No, I do not accept that, and I've had no trouble working around asserts I've 
gotten from other vendors' compilers, despite there being no message other than 
the compiler failed.

Most of the time it's the last change made that triggered it. Back up one
change 
and do something different.
Sep 03 2016
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Saturday, 3 September 2016 at 22:48:27 UTC, Walter Bright 
wrote:

 On 9/3/2016 6:20 AM, Adam D. Ruppe wrote:

 On Saturday, 3 September 2016 at 12:12:34 UTC, Walter Bright 
 wrote:

 Except that asserts are checking for compiler bugs, not 
 diagnostics on user code.


 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.


 Users are not equipped to do that, and we shouldn't raise false 
 expectations that they can. Developers who are equipped to that 
 are able and willing to build the compiler from source with 
 debugging turned on.

 Really, what possible use is there to an end user for an assert 
 that unhelpfully printed out a message that the register 
 allocator failed? There's nothing "user friendly" about a such 
 a message.



 I understand if you want to say producing better error 
 messages in the compiler
 is a pain and you have other priorities, but surely you accept 
 that they are
 valuable for this reason if nothing else.


 No, I do not accept that, and I've had no trouble working 
 around asserts I've gotten from other vendors' compilers, 
 despite there being no message other than the compiler failed.

 Most of the time it's the last change made that triggered it. 
 Back up one change and do something different.


In my experience getting a clue as to what is was the compiler 
didn't like is very useful. Often the only way I can find a 
workaround is by locating the assert in the compiler source and 
working out what it might possibly be to do with, then making 
informed guesses about what semi-equivalent code I can write that 
will avoid the bug.

If the assert just had a little more info, it might save me a 
fair amount of time.
Sep 03 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/3/2016 7:35 PM, John Colvin wrote:

 In my experience getting a clue as to what is was the compiler didn't like is
 very useful. Often the only way I can find a workaround is by locating the
 assert in the compiler source and working out what it might possibly be to do
 with, then making informed guesses about what semi-equivalent code I can write
 that will avoid the bug.

 If the assert just had a little more info, it might save me a fair amount of
time.


If you're willing to look at the file/line of where the assert tripped, I don't 
see how a message would save any time at all.
Sep 03 2016
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Sunday, 4 September 2016 at 05:13:49 UTC, Walter Bright wrote:

 On 9/3/2016 7:35 PM, John Colvin wrote:

 In my experience getting a clue as to what is was the compiler 
 didn't like is
 very useful. Often the only way I can find a workaround is by 
 locating the
 assert in the compiler source and working out what it might 
 possibly be to do
 with, then making informed guesses about what semi-equivalent 
 code I can write
 that will avoid the bug.

 If the assert just had a little more info, it might save me a 
 fair amount of time.


 If you're willing to look at the file/line of where the assert 
 tripped, I don't see how a message would save any time at all.


Because the message would give me a clue immediately, without me 
having to go looking in the compiler source (!). Also, I have a 
vague clue of how dmd works, because I'm interested, but someone 
else in my position with a compiler crash in front of them and a 
deadline to hit isn't going to want to have to understand it to 
find out "oh it's the variadic args marked scope that the 
compiler is messing up on".
Sep 04 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/4/2016 2:17 AM, John Colvin wrote:

 On Sunday, 4 September 2016 at 05:13:49 UTC, Walter Bright wrote:

 On 9/3/2016 7:35 PM, John Colvin wrote:

 In my experience getting a clue as to what is was the compiler didn't like is
 very useful. Often the only way I can find a workaround is by locating the
 assert in the compiler source and working out what it might possibly be to do
 with, then making informed guesses about what semi-equivalent code I can write
 that will avoid the bug.

 If the assert just had a little more info, it might save me a fair amount of
 time.


 If you're willing to look at the file/line of where the assert tripped, I
 don't see how a message would save any time at all.


 Because the message would give me a clue immediately, without me having to go
 looking in the compiler source (!). Also, I have a vague clue of how dmd works,
 because I'm interested,


I don't know why opening a file and navigating to a line would consume a fair 
amount of time.



 but someone else in my position with a compiler crash in
 front of them and a deadline to hit isn't going to want to have to understand
it
 to find out "oh it's the variadic args marked scope that the compiler is
messing
 up on".


I don't think that's realistic. It'd be like me trying to guess why I got a 
kernel panic.

As I mentioned before, assert failures are usually the result of the last edit 
one did. The problem is already narrowed down.
Sep 04 2016
next sibling parent reply develop32 <develop32 gmail.com> writes:
On Sunday, 4 September 2016 at 10:33:44 UTC, Walter Bright wrote:


 As I mentioned before, assert failures are usually the result 
 of the last edit one did. The problem is already narrowed down.


That's just not true in my case. Most of the asserts I triggered 
were after updating to a newer compiler version.

I don't find -v helpful as it only points to a single haystack 
out of many, I still have to find the needle. The backend source 
is hard to get into, it would really help to know a little bit 
more about the cause for the error.

One assert made me delay updating to a newer DMD version for like 
a year. I was reluctant to make the bug report because of the 
size of my codebase and inability to make a simple test case, I 
didn't even know for certain which function was the cause for it. 
Certainly just stating that an assert was triggered in this and 
this line of the backend is not enough?

Having more information would help create those bug reports.
Sep 04 2016
parent Dicebot <public dicebot.lv> writes:
On Sunday, 4 September 2016 at 10:46:25 UTC, develop32 wrote:

 Certainly just stating that an assert was triggered in this and 
 this line of the backend is not enough?


Often it is actually enough because compiler developer can check 
last changes to related code and propose simple checks to nail it 
down.

There shouldn't be any reason to not report ICE to bugzilla, no 
matter how few data can ne provided.
Sep 04 2016
prev sibling next sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Sunday, 4 September 2016 at 10:33:44 UTC, Walter Bright wrote:

 On 9/4/2016 2:17 AM, John Colvin wrote:

 On Sunday, 4 September 2016 at 05:13:49 UTC, Walter Bright 
 wrote:

 On 9/3/2016 7:35 PM, John Colvin wrote:

 In my experience getting a clue as to what is was the 
 compiler didn't like is
 very useful. Often the only way I can find a workaround is 
 by locating the
 assert in the compiler source and working out what it might 
 possibly be to do
 with, then making informed guesses about what 
 semi-equivalent code I can write
 that will avoid the bug.

 If the assert just had a little more info, it might save me 
 a fair amount of
 time.


 If you're willing to look at the file/line of where the 
 assert tripped, I
 don't see how a message would save any time at all.


 Because the message would give me a clue immediately, without 
 me having to go
 looking in the compiler source (!). Also, I have a vague clue 
 of how dmd works,
 because I'm interested,


 I don't know why opening a file and navigating to a line would 
 consume a fair amount of time.


Opening the file isn't the problem, it's understanding the 
context in order to get hints as to what confused the compiler.


 but someone else in my position with a compiler crash in
 front of them and a deadline to hit isn't going to want to


 have to understand it

 to find out "oh it's the variadic args marked scope that the


 compiler is messing

 up on".


 I don't think that's realistic. It'd be like me trying to guess 
 why I got a kernel panic.


Well I've had to do it, a lot, in order to get work done. I'm not 
working out what's wrong with the compiler, I'm just getting a 
little more information in order to make better educated guesses 
of how to make my code compile.


 As I mentioned before, assert failures are usually the result 
 of the last edit one did. The problem is already narrowed down.


Narrowed down a bit. Often I've just done a big refactoring 
and/or written a bunch of new code that could (and should) never 
compile in any intermediate state. The clues that I get from the 
compiler source prove invaluable in working out a path to 
something that works without having to scrap a whole bunch of 
good work.
Sep 04 2016
prev sibling parent Ethan Watson <gooberman gmail.com> writes:
On Sunday, 4 September 2016 at 10:33:44 UTC, Walter Bright wrote:

 As I mentioned before, assert failures are usually the result 
 of the last edit one did. The problem is already narrowed down.


I got the error at the start of the thread because I added a 
variable to a class. The class is having two mixins applied to 
it, which invoke templated code themselves. I knew that 
commenting out this variable would work around the problem - but 
it very definitely was not a good workaround as this struct is 
being used to match a C++ struct. Which meant I had to fumble my 
way through multiple mixins and templates working out what had 
actually caused the problem.

Saying an assert is the result of the last thing you did, sure, 
it tends to be correct. But it's not as simple in D as it was in 
the C/early C++ days, especially when mixins are already a pain 
to debug.
Sep 04 2016
prev sibling parent Ethan Watson <gooberman gmail.com> writes:
On Sunday, 4 September 2016 at 05:13:49 UTC, Walter Bright wrote:

 If you're willing to look at the file/line of where the assert 
 tripped, I don't see how a message would save any time at all.


The level builders at Remedy are going to be using D as a 
scripting language. If they get an error like this, they can't be 
expected to open a compiler's source code. Especially since as a 
part of the tool chain I won't be shipping it out to them.
Sep 04 2016
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Saturday, 3 September 2016 at 12:12:34 UTC, Walter Bright 
wrote:

 Except that asserts are checking for compiler bugs, not 
 diagnostics on user code. I don't expect users to debug the 
 compiler - if they get an assert they should file a bug report 
 to bugzilla and let us debug the compiler and fix it.


I suggest these assert come with a message explaining this is a 
compiler bug, and a link to the bug tracker + useful infos to 
include in the bug report in order to lower the barrier to get a 
bug report and make it clear to the user that it isn't a problem 
in their code with a obtuse error message.
Sep 05 2016
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
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.


There are three things that will ideally happen when someone sees 
an assert:

* They'll submit a bug report to bugzilla.
* They'll come up with a reasonably simple test case to add to 
the bug report.
* They'll find an immediate workaround for their code so they can 
get on with their life and not have to wait until the next 
compiler release.

The second and third would be greatly benefitted by the compiler 
attempting to tell us where the problem was encountered. For 
instance, if the assert was triggered while trying to generate 
code for function 
dmud.eventqueue.EventQueue!(Fiber).scheduleNear, I would know to 
look first and foremost at that function.

Yes, if I'm rebuilding my code often, I'll be able to narrow 
things down automatically, but I'm not as virtuous as I would 
like. And with templates, things get harder.
Sep 02 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/2/2016 2:54 PM, Chris Wright wrote:

 The second and third would be greatly benefitted by the compiler attempting to
 tell us where the problem was encountered. For instance, if the assert was
 triggered while trying to generate code for function
 dmud.eventqueue.EventQueue!(Fiber).scheduleNear, I would know to look first and
 foremost at that function.


Compiling with -v will usually show how far the compiler got.
Sep 02 2016
parent David Nadlinger <code klickverbot.at> writes:
On Friday, 2 September 2016 at 22:12:20 UTC, Walter Bright wrote:

 Compiling with -v will usually show how far the compiler got.


It's curious that this topic should come up now – just a couple 
of days ago, I thought about adding better user reporting for LDC 
ICEs.

What I was planning to do is to keep a global stack of locations 
(and symbols where applicable, to be able to print the name) that 
is updated as the AST is traversed during semantic and glue 
layer. This should be very cheap to do, especially since the 
information does not need to be perfect.

You can then install a custom assert/segfault handler to print 
that information to aid users in reducing a test case or working 
around the problem, even for hard crashes or ICEs. The location 
information needs to be just close enough that the user knows 
where to start looking if the error appears after a compiler 
upgrade or when writing template-heavy code.

  — David
Sep 02 2016