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.

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

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.

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.

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.

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.

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.

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

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.

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".)