DMD diagnostic - any way to remove identical lines from final dmd error log?

[Dmitry Olshansky]

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

[Don Clugston]

Post by Dmitry Olshansky
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.

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.

Post by Dmitry Olshansky
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

[Don Clugston]

Post by Don Clugston

Post by Dmitry Olshansky
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.

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.

Post by Dmitry Olshansky
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.

[Paulo Pinto]

Post by Don Clugston

Post by Don Clugston

Post by Dmitry Olshansky
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

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.

Post by Dmitry Olshansky
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

[Don Clugston]

Post by Paulo Pinto

Post by Don Clugston

Post by Don Clugston

Post by Dmitry Olshansky
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.

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.

Post by Dmitry Olshansky
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.

Post by Paulo Pinto
But I seem to be in the minority regarding compiler error messages.
--
Paulo

[Marco Leise]

Am Tue, 14 Aug 2012 12:15:35 +0200

Post by Don Clugston
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.

[Timon Gehr]

Post by Marco Leise
Am Tue, 14 Aug 2012 12:15:35 +0200

Post by Don Clugston
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_.

[Andrei Alexandrescu]

Post by Paulo Pinto
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

[Dmitry Olshansky]

Post by Don Clugston

Post by Don Clugston

Post by Dmitry Olshansky
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.

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.

Post by Don Clugston

Post by Don Clugston

Post by Dmitry Olshansky
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

Post by Don Clugston
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.