digitalmars.D.learn - filter out compile error messages involving _error_
- timotheecour (7/7) Sep 09 2012 Can we filter out compiler errors involving _error_ as template
- Timon Gehr (2/8) Sep 09 2012 You can file all instances of this you can find as 'diagnostic' bugs.
- Jonathan M Davis (9/17) Sep 09 2012 They're useful, because they give you the instantiation chain, and it ma...
- Timon Gehr (2/19) Sep 09 2012 Don has expressed the desire to weed those out completely.
- Jonathan M Davis (4/5) Sep 09 2012 If he can do it in a way that leaves in all of the necessary information...
- timotheecour (6/13) Sep 09 2012 On a related note, it would be much clearer if the error messages
- Don Clugston (3/8) Sep 10 2012 Yes, that's the idea. It's pretty much working for CTFE now (you get a
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
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
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
On 09/10/2012 02:14 AM, Jonathan M Davis wrote:On Monday, September 10, 2012 01:52:52 timotheecour wrote:Don has expressed the desire to weed those out completely.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
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
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
On 10/09/12 02:31, Jonathan M Davis wrote:On Monday, September 10, 2012 02:16:19 Timon Gehr wrote:Yes, that's the idea. It's pretty much working for CTFE now (you get a complete call stack, with no spurious error messages).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 10 2012