March 07, 2007
Frits van Bommel wrote:
> Don Clugston wrote:
>>
>> Given how common static assert(0) is, I wonder if something could be done to improve the error message quality in the
>> "static assert(0, "xxx")" case?
>>
>> file.d(58): static assert  (0) is false, "xxx"
>>
>> Maybe drop out the "(0) is false" bit, since it doesn't seem to add much value, changing it to something like:
>>
>> file.d(58): static assert, "xxx"
>>
>> Or even drop the 'static assert' bit entirely, and just display "xxx".
> 
> I don't think dropping the 'static assert' bit is a good idea (at least, without replacing it with something of similar meaning). I think it's a good thing that static asserts are clearly distinct from compiler-generated errors. The exact wording could be different but it should be clear that this is an error because the author of the code explicitly _made_ it one, not because of any inherent language rule (other than the one on static assert, obviously).

Why is it important to distinguish between an error that's detected in a library, compared to one that is detected by the compiler? I would think that a library writer would have the decency to explain in the text of the error, that the error occurred in the library.

somefile.d(25): "SnazzySQL: Syntax error in SQL statement 'SELET * FROM CUSTOMERS'"

(You could be correct, it's just not obvious to me).
March 07, 2007
Pragma wrote:
> BCS wrote:
> 
>> Reply to Walter,
>>
>>> BCS wrote:
>>>
>>>> Why do the static asserts get processed later?
>>>>
>>>> I'd expect that having them get processed sooner would make things
>>>> work nicer.
>>>>
>>> There's always that chicken-and-egg problem of forward references.
>>>
>>
>> Ah!!
>>
>> Wild thought: I know it's to late to do this for for DMD but, what would the problems be of doing a lazy evaluation of the AST?
>> I'm thinking something like; process the declarations and statements in order (starting at the module level) and when you find a symbol you don't know about go looking for it.
>>
>>
> 
> Interesting idea.  Maybe I'm just naive, but how would this be any different than just adding an additional semantic pass, while relaxing DMD's tendency to barf on unresolved symbols - or is that what you're proposing?
> 

You can't do it in a constant number of passes because asserts can depend on templates that depend on asserts that depend on templates ...
March 07, 2007
Don Clugston wrote:
> Frits van Bommel wrote:
>> Don Clugston wrote:
>>>
>>> Given how common static assert(0) is, I wonder if something could be done to improve the error message quality in the
>>> "static assert(0, "xxx")" case?
>>>
>>> file.d(58): static assert  (0) is false, "xxx"
>>>
>>> Maybe drop out the "(0) is false" bit, since it doesn't seem to add much value, changing it to something like:
>>>
>>> file.d(58): static assert, "xxx"
>>>
>>> Or even drop the 'static assert' bit entirely, and just display "xxx".
>>
>> I don't think dropping the 'static assert' bit is a good idea (at least, without replacing it with something of similar meaning). I think it's a good thing that static asserts are clearly distinct from compiler-generated errors. The exact wording could be different but it should be clear that this is an error because the author of the code explicitly _made_ it one, not because of any inherent language rule (other than the one on static assert, obviously).
> 
> Why is it important to distinguish between an error that's detected in a library, compared to one that is detected by the compiler? I would think that a library writer would have the decency to explain in the text of the error, that the error occurred in the library.
> 
> somefile.d(25): "SnazzySQL: Syntax error in SQL statement 'SELET * FROM CUSTOMERS'"
> 
> (You could be correct, it's just not obvious to me).

There may be other reasons, but often IDEs will take you to lines where errors were generated, sorting those that are errors ahead of lines that were warnings or informational or what have you.

For that to work though, prefixes need to be consistent.  An IDE won't know if "SnazzySQL" is an error a warning or what.  So from my POV at least static asserts should be prefixed with *something* fixed, but I don't care so much if it's just "somefile.d(25): Error" or "somefile.d(25): static assert.

If the latter then an IDE could have a rule that prioritizes static asserts over other errors.  Don't know how useful that would be though.  Seems common to only distinguish 3 categories -- Error (this won't compile),  Warning (this might cause trouble at runtime), Information ("hey I'm going to link with phobos.lib, ok?")

--bb
March 07, 2007
Don Clugston wrote:
> Frits van Bommel wrote:
> 
>> Don Clugston wrote:
>>
>>>
>>> Given how common static assert(0) is, I wonder if something could be done to improve the error message quality in the
>>> "static assert(0, "xxx")" case?
>>>
>>> file.d(58): static assert  (0) is false, "xxx"
>>>
>>> Maybe drop out the "(0) is false" bit, since it doesn't seem to add much value, changing it to something like:
>>>
>>> file.d(58): static assert, "xxx"
>>>
>>> Or even drop the 'static assert' bit entirely, and just display "xxx".
>>
>>
>> I don't think dropping the 'static assert' bit is a good idea (at least, without replacing it with something of similar meaning). I think it's a good thing that static asserts are clearly distinct from compiler-generated errors. The exact wording could be different but it should be clear that this is an error because the author of the code explicitly _made_ it one, not because of any inherent language rule (other than the one on static assert, obviously).
> 
> 
> Why is it important to distinguish between an error that's detected in a library, compared to one that is detected by the compiler? I would think that a library writer would have the decency to explain in the text of the error, that the error occurred in the library.
> 
> somefile.d(25): "SnazzySQL: Syntax error in SQL statement 'SELET * FROM CUSTOMERS'"
> 
> (You could be correct, it's just not obvious to me).

1) Never trust convention or decency to make people do something that is *needed*

2) compile errors are usually the fault of the lib, asserts are the fault of the user. Also the asserts will probably be more useful when trying to fix things.
March 07, 2007
BCS wrote:
> Don Clugston wrote:
>> Frits van Bommel wrote:
>>
>>> Don Clugston wrote:
>>>
>>>>
>>>> Given how common static assert(0) is, I wonder if something could be done to improve the error message quality in the
>>>> "static assert(0, "xxx")" case?
>>>>
>>>> file.d(58): static assert  (0) is false, "xxx"
>>>>
>>>> Maybe drop out the "(0) is false" bit, since it doesn't seem to add much value, changing it to something like:
>>>>
>>>> file.d(58): static assert, "xxx"
>>>>
>>>> Or even drop the 'static assert' bit entirely, and just display "xxx".
>>>
>>>
>>> I don't think dropping the 'static assert' bit is a good idea (at least, without replacing it with something of similar meaning). I think it's a good thing that static asserts are clearly distinct from compiler-generated errors. The exact wording could be different but it should be clear that this is an error because the author of the code explicitly _made_ it one, not because of any inherent language rule (other than the one on static assert, obviously).
>>
>>
>> Why is it important to distinguish between an error that's detected in a library, compared to one that is detected by the compiler? I would think that a library writer would have the decency to explain in the text of the error, that the error occurred in the library.
>>
>> somefile.d(25): "SnazzySQL: Syntax error in SQL statement 'SELET * FROM CUSTOMERS'"
>>
>> (You could be correct, it's just not obvious to me).
> 
> 1) Never trust convention or decency to make people do something that is *needed*

IMHO, it's not *needed*, just nice.

> 2) compile errors are usually the fault of the lib, asserts are the fault of the user. Also the asserts will probably be more useful when trying to fix things.

I'm only talking about the specific case of static assert(0, "xxx");
-- giving the library writer an option to suppress the "static assert" message.
March 07, 2007
Bill Baxter wrote:
> Don Clugston wrote:
>> Frits van Bommel wrote:
>>> Don Clugston wrote:
>>>>
>>>> Given how common static assert(0) is, I wonder if something could be done to improve the error message quality in the
>>>> "static assert(0, "xxx")" case?
>>>>
>>>> file.d(58): static assert  (0) is false, "xxx"
>>>>
>>>> Maybe drop out the "(0) is false" bit, since it doesn't seem to add much value, changing it to something like:
>>>>
>>>> file.d(58): static assert, "xxx"
>>>>
>>>> Or even drop the 'static assert' bit entirely, and just display "xxx".
>>>
>>> I don't think dropping the 'static assert' bit is a good idea (at least, without replacing it with something of similar meaning). I think it's a good thing that static asserts are clearly distinct from compiler-generated errors. The exact wording could be different but it should be clear that this is an error because the author of the code explicitly _made_ it one, not because of any inherent language rule (other than the one on static assert, obviously).
>>
>> Why is it important to distinguish between an error that's detected in a library, compared to one that is detected by the compiler? I would think that a library writer would have the decency to explain in the text of the error, that the error occurred in the library.
>>
>> somefile.d(25): "SnazzySQL: Syntax error in SQL statement 'SELET * FROM CUSTOMERS'"
>>
>> (You could be correct, it's just not obvious to me).
> 
> There may be other reasons, but often IDEs will take you to lines where errors were generated, sorting those that are errors ahead of lines that were warnings or informational or what have you.
> 
> For that to work though, prefixes need to be consistent.  An IDE won't know if "SnazzySQL" is an error a warning or what.  So from my POV at least static asserts should be prefixed with *something* fixed, but I don't care so much if it's just "somefile.d(25): Error" or "somefile.d(25): static assert.
> 
> If the latter then an IDE could have a rule that prioritizes static asserts over other errors.  Don't know how useful that would be though.  Seems common to only distinguish 3 categories -- Error (this won't compile),  Warning (this might cause trouble at runtime), Information ("hey I'm going to link with phobos.lib, ok?")

Fair enough, but existing DMD error messages don't do that.

file.d(729): found 'auto' when expecting ';' following 'statement'

so it's a general issue. But since Walter doesn't like warnings, they're all errors anyway.
1 2
Next ›   Last »