www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - filter out compile error messages involving _error_

reply "timotheecour" <thelastmammoth gmail.com> writes:
Can we filter out compiler errors involving _error_ as template 
parameter?
Clearly the error is coming from upstream so there's no need to 
even show those.

eg:
Error: template mypackage.mymodule.myfunction cannot deduce 
template function from argument types !()(_error_)
Sep 09 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/10/2012 01:52 AM, timotheecour wrote:
 Can we filter out compiler errors involving _error_ as template parameter?
 Clearly the error is coming from upstream so there's no need to even
 show those.

 eg:
 Error: template mypackage.mymodule.myfunction cannot deduce template
 function from argument types !()(_error_)
You can file all instances of this you can find as 'diagnostic' bugs.
Sep 09 2012
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, September 10, 2012 01:52:52 timotheecour wrote:
 Can we filter out compiler errors involving _error_ as template
 parameter?
 Clearly the error is coming from upstream so there's no need to
 even show those.
 
 eg:
 Error: template mypackage.mymodule.myfunction cannot deduce
 template function from argument types !()(_error_)
They're useful, because they give you the instantiation chain, and it makes it clear why each instantiation is failing. Yes, what you ultimately need to fix is what's resulting in _error_, but that doesn't mean that the rest is useless (like knowing _where_ the template was instantiatied from and what arguments were used to instantiate it). If you don't want to see those, then use grep -v _error_ on the compiler's output. - Jonathan M Davis
Sep 09 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/10/2012 02:14 AM, Jonathan M Davis wrote:
 On Monday, September 10, 2012 01:52:52 timotheecour wrote:
 Can we filter out compiler errors involving _error_ as template
 parameter?
 Clearly the error is coming from upstream so there's no need to
 even show those.

 eg:
 Error: template mypackage.mymodule.myfunction cannot deduce
 template function from argument types !()(_error_)
They're useful, because they give you the instantiation chain, and it makes it clear why each instantiation is failing. Yes, what you ultimately need to fix is what's resulting in _error_, but that doesn't mean that the rest is useless (like knowing _where_ the template was instantiatied from and what arguments were used to instantiate it). If you don't want to see those, then use grep -v _error_ on the compiler's output. - Jonathan M Davis
Don has expressed the desire to weed those out completely.
Sep 09 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, September 10, 2012 02:16:19 Timon Gehr wrote:
 Don has expressed the desire to weed those out completely.
If he can do it in a way that leaves in all of the necessary information, then great, but you need to be able to know what the instantiation chain was. - Jonathan M Davis
Sep 09 2012
next sibling parent "timotheecour" <thelastmammoth gmail.com> writes:
On a related note, it would be much clearer if the error messages 
used fullyQualifiedName!T instead of just the type name T, as in 
more complex code, there WILL be name clashes.
I would guess this would be easy to fix.

On Monday, 10 September 2012 at 00:30:54 UTC, Jonathan M Davis 
wrote:
 On Monday, September 10, 2012 02:16:19 Timon Gehr wrote:
 Don has expressed the desire to weed those out completely.
If he can do it in a way that leaves in all of the necessary information, then great, but you need to be able to know what the instantiation chain was. - Jonathan M Davis
Sep 09 2012
prev sibling parent Don Clugston <dac nospam.com> writes:
On 10/09/12 02:31, Jonathan M Davis wrote:
 On Monday, September 10, 2012 02:16:19 Timon Gehr wrote:
 Don has expressed the desire to weed those out completely.
If he can do it in a way that leaves in all of the necessary information, then great, but you need to be able to know what the instantiation chain was. - Jonathan M Davis
Yes, that's the idea. It's pretty much working for CTFE now (you get a complete call stack, with no spurious error messages).
Sep 10 2012