Community

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