Quality of errors in DMD

[John Colvin via Digitalmars-d]

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.