www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD diagnostic - any way to remove identical lines from final dmd

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
I seriously consider writing a simple postprocessor for dmd's output.
Once dmd became able to recover from errors and crawl on it started to 
produce horrific amounts of redundant text on failure.

Observe for instance that there are only 6 + 2 = 8 lines of interest:

uni.d(3699): Error: template instance uni.icmp!(char,wchar) error 
instantiating
uni.d(3683): Error: undefined identifier fullCasedMatch
uni.d(3686): Error: undefined identifier fullCasedMatch
uni.d(3699): Error: template instance uni.icmp!(char,dchar) error 
instantiating
uni.d(3683): Error: undefined identifier fullCasedMatch
uni.d(3686): Error: undefined identifier fullCasedMatch
uni.d(3699): Error: template instance uni.icmp!(wchar,char) error 
instantiating
uni.d(3683): Error: undefined identifier fullCasedMatch
uni.d(3686): Error: undefined identifier fullCasedMatch
uni.d(3699): Error: template instance uni.icmp!(wchar,wchar) error 
instantiating
uni.d(3683): Error: undefined identifier fullCasedMatch
uni.d(3686): Error: undefined identifier fullCasedMatch
uni.d(3699): Error: template instance uni.icmp!(wchar,dchar) error 
instantiating
uni.d(3683): Error: undefined identifier fullCasedMatch
uni.d(3686): Error: undefined identifier fullCasedMatch
uni.d(3699): Error: template instance uni.icmp!(dchar,char) error 
instantiating

I'd ideally see this:

uni.d(3683): Error: undefined identifier fullCasedMatch
uni.d(3686): Error: undefined identifier fullCasedMatch
--- !! During instantiation of ---
uni.d(3699): template instance uni.icmp!(char,dchar)
uni.d(3699): template instance uni.icmp!(char,wchar)
uni.d(3699): template instance uni.icmp!(char,dchar)
uni.d(3699): template instance uni.icmp!(wchar,wchar)
uni.d(3699): template instance uni.icmp!(wchar,dchar)
uni.d(3699): template instance uni.icmp!(dchar,char)
-------
... other errors

Other food for thought is to try to indicate explicitly which errors
are related vs unrelated, which are collateral, like failed template 
instantiation that rolls out the whole path of failure (but one have to 
read the text carefully to get where it starts).

-- 
Dmitry Olshansky
Aug 13 2012
next sibling parent reply Don Clugston <dac nospam.com> writes:
On 13/08/12 18:47, Dmitry Olshansky wrote:

 I seriously consider writing a simple postprocessor for dmd's output.
 Once dmd became able to recover from errors and crawl on it started to
 produce horrific amounts of redundant text on failure.

 Observe for instance that there are only 6 + 2 = 8 lines of interest:


Spurious or repeated error messages should be considered to be bugs.
Please put test cases in Bugzilla. A long time ago, the compiler used to 
spew reams of garbage all the time. Now it rarely happens.


 Other food for thought is to try to indicate explicitly which errors
 are related vs unrelated, which are collateral, like failed template
 instantiation that rolls out the whole path of failure (but one have to
 read the text carefully to get where it starts).


That's already happening. Supplemental messages don't have the word 
'Error' at the start of the error message.
There are still cases where
Aug 13 2012
parent reply Don Clugston <dac nospam.com> writes:
On 14/08/12 08:59, Don Clugston wrote:

 On 13/08/12 18:47, Dmitry Olshansky wrote:

 I seriously consider writing a simple postprocessor for dmd's output.
 Once dmd became able to recover from errors and crawl on it started to
 produce horrific amounts of redundant text on failure.

 Observe for instance that there are only 6 + 2 = 8 lines of interest:


 Spurious or repeated error messages should be considered to be bugs.
 Please put test cases in Bugzilla. A long time ago, the compiler used to
 spew reams of garbage all the time. Now it rarely happens.


 Other food for thought is to try to indicate explicitly which errors
 are related vs unrelated, which are collateral, like failed template
 instantiation that rolls out the whole path of failure (but one have to
 read the text carefully to get where it starts).


 That's already happening. Supplemental messages don't have the word
 'Error' at the start of the error message.


One fairly easy way to solve this, would be that once a template 
*instantiation* has failed, the template *definition* would be marked as 
doubtful, and any further instantiation using that definition would have 
all error messages suppressed. If an error occurred, a single error 
would be produced stating that the template instantiation failed.

The downside would be that if the template instantiation failed for a 
completely different reason the second time, its root cause error would 
not be shown. But this latest release is the only time such errors have 
been shown anyway.
Aug 14 2012
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 14 August 2012 at 08:48:14 UTC, Don Clugston wrote:

 On 14/08/12 08:59, Don Clugston wrote:

 On 13/08/12 18:47, Dmitry Olshansky wrote:

 I seriously consider writing a simple postprocessor for dmd's 
 output.
 Once dmd became able to recover from errors and crawl on it 
 started to
 produce horrific amounts of redundant text on failure.

 Observe for instance that there are only 6 + 2 = 8 lines of 
 interest:


 Spurious or repeated error messages should be considered to be 
 bugs.
 Please put test cases in Bugzilla. A long time ago, the 
 compiler used to
 spew reams of garbage all the time. Now it rarely happens.


 Other food for thought is to try to indicate explicitly which 
 errors
 are related vs unrelated, which are collateral, like failed 
 template
 instantiation that rolls out the whole path of failure (but 
 one have to
 read the text carefully to get where it starts).


 That's already happening. Supplemental messages don't have the 
 word
 'Error' at the start of the error message.


 One fairly easy way to solve this, would be that once a 
 template *instantiation* has failed, the template *definition* 
 would be marked as doubtful, and any further instantiation 
 using that definition would have all error messages suppressed. 
 If an error occurred, a single error would be produced stating 
 that the template instantiation failed.

 The downside would be that if the template instantiation failed 
 for a completely different reason the second time, its root 
 cause error would not be shown. But this latest release is the 
 only time such errors have been shown anyway.


Personally I loved the way Turbo Pascal used to work with compile 
failure on the first error.

Thanks to the fast compile times, it was easier and faster to 
fix-compile-find_next_error, than try to sort out the real errors 
from a dump of error messages.

But I seem to be in the minority regarding compiler error 
messages.

--
Paulo
Aug 14 2012
next sibling parent reply Don Clugston <dac nospam.com> writes:
On 14/08/12 11:32, Paulo Pinto wrote:

 On Tuesday, 14 August 2012 at 08:48:14 UTC, Don Clugston wrote:

 On 14/08/12 08:59, Don Clugston wrote:

 On 13/08/12 18:47, Dmitry Olshansky wrote:

 I seriously consider writing a simple postprocessor for dmd's output.
 Once dmd became able to recover from errors and crawl on it started to
 produce horrific amounts of redundant text on failure.

 Observe for instance that there are only 6 + 2 = 8 lines of interest:


 Spurious or repeated error messages should be considered to be bugs.
 Please put test cases in Bugzilla. A long time ago, the compiler used to
 spew reams of garbage all the time. Now it rarely happens.


 Other food for thought is to try to indicate explicitly which errors
 are related vs unrelated, which are collateral, like failed template
 instantiation that rolls out the whole path of failure (but one have to
 read the text carefully to get where it starts).


 That's already happening. Supplemental messages don't have the word
 'Error' at the start of the error message.


 One fairly easy way to solve this, would be that once a template
 *instantiation* has failed, the template *definition* would be marked
 as doubtful, and any further instantiation using that definition would
 have all error messages suppressed. If an error occurred, a single
 error would be produced stating that the template instantiation failed.

 The downside would be that if the template instantiation failed for a
 completely different reason the second time, its root cause error
 would not be shown. But this latest release is the only time such
 errors have been shown anyway.


 Personally I loved the way Turbo Pascal used to work with compile
 failure on the first error.

 Thanks to the fast compile times, it was easier and faster to
 fix-compile-find_next_error, than try to sort out the real errors from a
 dump of error messages.


To the best of my knowledge, DMD gives very few error messages which are 
not real. Every release, I eliminate a couple more spurious ones. It's 
starting to be difficult to find them.

Seriously, if you are finding ANY error messages for things which are 
not real errors, that is a bug.



 But I seem to be in the minority regarding compiler error messages.

 --
 Paulo
Aug 14 2012
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 14 Aug 2012 12:15:35 +0200
schrieb Don Clugston <dac nospam.com>:


 Seriously, if you are finding ANY error messages for things which are 
 not real errors, that is a bug.


What about errors that are a result of erroneous types being
used. Sometimes I read foo!(bar, _error_) in the error output
and wonder if that helps me any, since the error is obviously
farther above.

-- 
Marco
Aug 17 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/17/2012 02:17 PM, Marco Leise wrote:

 Am Tue, 14 Aug 2012 12:15:35 +0200
 schrieb Don Clugston<dac nospam.com>:


 Seriously, if you are finding ANY error messages for things which are
 not real errors, that is a bug.


 What about errors that are a result of erroneous types being
 used. Sometimes I read foo!(bar, _error_) in the error output
 and wonder if that helps me any, since the error is obviously
 farther above.


The user should never see _error_.
Aug 17 2012
parent "timotheecour" <timothee.cour2 gmail.com> writes:
On Friday, 17 August 2012 at 13:10:52 UTC, Timon Gehr wrote:

 On 08/17/2012 02:17 PM, Marco Leise wrote:

 Am Tue, 14 Aug 2012 12:15:35 +0200
 schrieb Don Clugston<dac nospam.com>:


 Seriously, if you are finding ANY error messages for things 
 which are
 not real errors, that is a bug.


 What about errors that are a result of erroneous types being
 used. Sometimes I read foo!(bar, _error_) in the error output
 and wonder if that helps me any, since the error is obviously
 farther above.


 The user should never see _error_.


just filed: https://issues.dlang.org/show_bug.cgi?id=14905
Aug 10 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/14/12 5:32 AM, Paulo Pinto wrote:

 Personally I loved the way Turbo Pascal used to work with compile
 failure on the first error.

 Thanks to the fast compile times, it was easier and faster to
 fix-compile-find_next_error, than try to sort out the real errors from a
 dump of error messages.

 But I seem to be in the minority regarding compiler error messages.


I guess the "head" command can be of use here!

Andrei
Aug 14 2012
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 14-Aug-12 12:48, Don Clugston wrote:

 On 14/08/12 08:59, Don Clugston wrote:

 On 13/08/12 18:47, Dmitry Olshansky wrote:

 I seriously consider writing a simple postprocessor for dmd's output.
 Once dmd became able to recover from errors and crawl on it started to
 produce horrific amounts of redundant text on failure.

 Observe for instance that there are only 6 + 2 = 8 lines of interest:


 Spurious or repeated error messages should be considered to be bugs.
 Please put test cases in Bugzilla. A long time ago, the compiler used to
 spew reams of garbage all the time. Now it rarely happens.




Will do.


 Other food for thought is to try to indicate explicitly which errors
 are related vs unrelated, which are collateral, like failed template
 instantiation that rolls out the whole path of failure (but one have to
 read the text carefully to get where it starts).


 That's already happening. Supplemental messages don't have the word
 'Error' at the start of the error message.


 One fairly easy way to solve this, would be that once a template
 *instantiation* has failed, the template *definition* would be marked as
 doubtful, and any further instantiation using that definition would have
 all error messages suppressed. If an error occurred, a single error
 would be produced stating that the template instantiation failed.


I think it would be nice to merge different template instantiation 
failures with identical lists of error messages (or simply same lines). 
In my case all of them have the same error list (2 lines), in general it 
may end up having few different groups of failed instantiations


 The downside would be that if the template instantiation failed for a
 completely different reason the second time, its root cause error would
 not be shown.


Yes, see the idea above.
Aug 14 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/13/2012 9:47 AM, Dmitry Olshansky wrote:

 I seriously consider writing a simple postprocessor for dmd's output.
 Once dmd became able to recover from errors and crawl on it started to produce
 horrific amounts of redundant text on failure.


The current strategy the compiler uses on detecting a bug is it marks whatever 
symbol/expression/statement caused the bug as "poisoned". Then, every
dependency 
on that poisoned symbol/expression/statement is also marked as "poisoned" and 
error messages for them are suppressed.

This has been extremely successful at reducing cascaded, duplicated, and 
nonsense error messages.

However, it is not completely implemented throughout the compiler.
Aug 10 2015