Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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" ?
Re: Quality of errors in DMD
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
Re: Quality of errors in DMD
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".)
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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".
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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."
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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 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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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 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
Re: Quality of errors in DMD
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...
Re: Quality of errors in DMD
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 signature.asc Description: OpenPGP digital signature
Re: Quality of errors in DMD
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
Re: Quality of errors in DMD
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.
Re: Quality of errors in DMD
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
Quality of errors in DMD
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.
