Hello all, and sorry for getting into this a bit late. I have a
question concerning this patch:
+++ cp/call.c (working copy)
[...]
+static const char *
+op_error_string (const char *err_msg, int ntypes, bool match)
+{
+ const char *msg;
+
+ const char *msgt = concat (match ?
On Thu, Apr 26, 2012 at 5:34 AM, Dodji Seketeli do...@seketeli.org wrote:
Hello all, and sorry for getting into this a bit late. I have a
question concerning this patch:
+++ cp/call.c (working copy)
[...]
+static const char *
+op_error_string (const char *err_msg, int ntypes, bool match)
Hi,
On 04/26/2012 03:27 PM, Gabriel Dos Reis wrote:
yes, it does. On the other hand, the program is going to exit soon...
-- Gaby
In any case, a bit of sloppiness on my part. Sorry about that. Now, all
in all I don't have a strong opinion, but we may want to apply something
like the below
On Mon, Apr 16, 2012 at 12:42 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Sun, 15 Apr 2012, Gabriel Dos Reis wrote:
a hybrid approach; I would suggest something like this: (a) if caret
is in effect, then print
the caret pointing to the symbol in question; otherwise (b) print the
symbol
On Mon, Apr 16, 2012 at 8:31 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
On Mon, Apr 16, 2012 at 12:42 AM, Marc Glissemarc.gli...@inria.fr
wrote:
On Sun, 15 Apr 2012, Gabriel Dos Reis wrote:
a hybrid approach; I would suggest something like this: (a) if caret
is in effect, then
.. hi all, hi Gaby,
a couple of days ago, Manuel suggested in the audit trail of the main
caret diagnostics PR, that now that we actually have got a form of it,
the kind of change I proposed to resolve PR 49152 may make much more
sense. In any case, my original patch still regtests fine
On Sun, 15 Apr 2012, Gabriel Dos Reis wrote:
a hybrid approach; I would suggest something like this: (a) if caret
is in effect, then print
the caret pointing to the symbol in question; otherwise (b) print the
symbol and the type (as suggested by Marc).
I may have forgotten the details, but
Hi,
On 03/22/2012 05:25 AM, Gabriel Dos Reis wrote:
On Wed, Mar 21, 2012 at 7:22 PM, Paolo Carlinipaolo.carl...@oracle.com wrote:
Hi,
this diagnostic issue is about not even trying to print expressions in error
messages involving operators, and print operand types instead. Just as an
On Thu, 22 Mar 2012, Paolo Carlini wrote:
Hi,
On 03/22/2012 05:25 AM, Gabriel Dos Reis wrote:
On Wed, Mar 21, 2012 at 7:22 PM, Paolo Carlinipaolo.carl...@oracle.com
wrote:
Hi,
this diagnostic issue is about not even trying to print expressions in
error
messages involving operators, and
On Thu, Mar 22, 2012 at 11:13 AM, Marc Glisse marc.gli...@inria.fr wrote:
I haven't followed the whole diagnostic discussion, but what about printing
both the reconstructed expression and the types?
Printing both isn't really the issue -- and we probably should. (And I thought
we did in some
Hi,
this diagnostic issue is about not even trying to print expressions in
error messages involving operators, and print operand types instead.
Just as an example, for:
struct X { int x; };
void trigger (X x []) { x [01] = 0; }
we currently print:
error: no match for ‘operator=’ in ‘*(x +
On Wed, Mar 21, 2012 at 7:22 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
this diagnostic issue is about not even trying to print expressions in error
messages involving operators, and print operand types instead. Just as an
example, for:
struct X { int x; };
void trigger (X x [])
12 matches
Mail list logo