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.

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.

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

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.

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.

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.

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

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.

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.

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.