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
Hi again,
thus the below is what I booted and tested. As you can see I had to
tweak a bit an existing testcase, for which the location is now a bit
"smaller", 3 chars, in fact is still not perfect, but arguably a tad
better. Otherwise no issues. Ah, I'm touching also a c-common.c
function, in
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
Hi,
for this testcase:
int main()
{
auto a = []() { return true; };
auto b = []() { return a(); }; // { dg-error "'a' is not captured" }
int c, d;
while (b() && c < d)
{
}
}
we produce meaningless diagnostics for the while loop (stemming from b()
but the caret is also in the wrong place, a sep
20 matches
Mail list logo
