On 05/09/2012 02:47 PM, Paolo Carlini wrote:
+ error_at(loc, "cannot bind bitfield %qE to %qT",
Missing a space.
OK with that change.
Jason
On 05/09/2012 03:20 PM, Jason Merrill wrote:
I think the problem is you really want to use EXPR_LOC_OR_HERE rather
than location_of; if the argument happens to be a DECL, location_of
will give you the declaration location rather than the use location.
Ah! Thanks a lot, now all those small detail
On 05/09/2012 09:04 AM, Manuel López-Ibáñez wrote:
This far less clear than error_at(location, "whatever"). And it
requires the diagnostics machinery to know about input_location. I
removed %H precisely for those reasons. Please, let's stop using "+"
in diagnostics and always use explicit locatio
I think the problem is you really want to use EXPR_LOC_OR_HERE rather
than location_of; if the argument happens to be a DECL, location_of will
give you the declaration location rather than the use location.
Jason
Hi,
On 05/09/2012 02:59 PM, Jason Merrill wrote:
On 05/09/2012 08:21 AM, Paolo Carlini wrote:
Is unapplied because I was really nervous due to the wrong location
(thus caret) of the error call, at the end of the whole condition. Now,
I'm wondering, shall we consistently use error_at (location_o
On 9 May 2012 14:59, Jason Merrill wrote:
> On 05/09/2012 08:21 AM, Paolo Carlini wrote:
>>
>> Is unapplied because I was really nervous due to the wrong location
>> (thus caret) of the error call, at the end of the whole condition. Now,
>> I'm wondering, shall we consistently use error_at (locati
On 05/09/2012 08:21 AM, Paolo Carlini wrote:
Is unapplied because I was really nervous due to the wrong location
(thus caret) of the error call, at the end of the whole condition. Now,
I'm wondering, shall we consistently use error_at (location_of (expr),
... for the error messages produced by th
Hi again,
On 05/08/2012 03:00 PM, Jason Merrill wrote:
On 05/07/2012 11:28 PM, Paolo Carlini wrote:
error: could not convert ‘b.main()::()’ from ‘void’ to ‘bool’
It wouldn't say "operator()"?
I think I'd leave that alone; it is somewhat more informative (about
what b() expands to) and we're
On 05/08/2012 03:00 PM, Jason Merrill wrote:
On 05/07/2012 11:28 PM, Paolo Carlini wrote:
error: could not convert ‘b.main()::()’ from ‘void’ to ‘bool’
It wouldn't say "operator()"?
Nope, it says exactly the above. If you tell me what would be more
sensible which remaining informative, I can
On 05/07/2012 11:28 PM, Paolo Carlini wrote:
error: could not convert ‘b.main()::()’ from ‘void’ to ‘bool’
It wouldn't say "operator()"?
I think I'd leave that alone; it is somewhat more informative (about
what b() expands to) and we're moving toward replacing %qE with caret
anyway.
The pa
On 05/08/2012 04:10 AM, Jason Merrill wrote:
How do we even get to calling cp_truthvalue_conversion?
ocp_convert wants to do that, around line 750... And I have a brand new
proposal ;)
The patchlet below (which passes testing) leads to very consistent error
messages for the testcase in the PR
How do we even get to calling cp_truthvalue_conversion?
Jason
On 05/07/2012 08:23 PM, Paolo Carlini wrote:
Index: typeck.c
===
--- typeck.c(revision 187249)
+++ typeck.c(working copy)
@@ -4782,7 +4782,11 @@ cp_truthvalue_conversion (tree expr)
return ret;
}
else
-retu
Hi,
On 05/07/2012 08:07 PM, Manuel López-Ibáñez wrote:
On 7 May 2012 19:40, Paolo Carlini wrote:
On 05/07/2012 07:18 PM, Paolo Carlini wrote:
a.cc:5:12: error: could not convert ‘foo()’ from ‘void’ to ‘bool’
if (foo())
Is this the error message we want to see for the former testcase, or w
On 7 May 2012 19:40, Paolo Carlini wrote:
> On 05/07/2012 07:18 PM, Paolo Carlini wrote:
>
> a.cc:5:12: error: could not convert ‘foo()’ from ‘void’ to ‘bool’
> if (foo())
>
> Is this the error message we want to see for the former testcase, or we want
> something slightly different?
If "foo()"
On 05/07/2012 07:18 PM, Paolo Carlini wrote:
On 05/07/2012 07:16 PM, Jason Merrill wrote:
I don't think the diagnostic is meaningless; since a() is ill-formed,
b() has type void.
Sure we do understand it ;)
But we ought to give a more helpful message when an expression used
as a truth value
On 05/07/2012 07:16 PM, Jason Merrill wrote:
I don't think the diagnostic is meaningless; since a() is ill-formed,
b() has type void.
Sure we do understand it ;)
But we ought to give a more helpful message when an expression used
as a truth value has an unsuitable type.
Thus something much mo
I don't think the diagnostic is meaningless; since a() is ill-formed,
b() has type void. But we ought to give a more helpful message when an
expression used as a truth value has an unsuitable type.
Jason
18 matches
Mail list logo
