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

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.

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

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.

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

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

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