[expr-cumulative] RFA: fix explicit operator parsing

[expr-cumulative] RFA: fix explicit operator parsing

[Tom Tromey]

While looking at a bug I found that expr-cumulative does not handle one
case of explicit calls to an operator:

    (gdb) p operator==(s1,s2)
    A syntax error in expression, near `operator==(s1,s2)'.

The bug is that the name_not_typename production does not handle
operator.

This patch fixes the problem and adds a couple new test cases -- one for
the bug and one for an explicit call to an operator as a member
function; I couldn't find one of these in the test suite.

Built and regtested on x86-64 (compile farm).
Ok?

Tom

2010-01-27  Tom Tromey  <tromey@redhat.com>

	* c-exp.y (name_not_typename): Add production for 'operator'.

2010-01-27  Tom Tromey  <tromey@redhat.com>

	* gdb.cp/userdef.exp: Add tests for explicit use of operator==.
	* gdb.cp/userdef.cc (operator==): New function.
	(main): New variables 'mem1', 'mem2'.

diff --git a/gdb/c-exp.y b/gdb/c-exp.y
index 92efb39..b86fc8e 100644
--- a/gdb/c-exp.y
+++ b/gdb/c-exp.y
@@ -1317,6 +1317,14 @@ name_not_typename :	NAME
    context where only a name could occur, this might be useful.
   	|	NAME_OR_INT
  */
+	|	operator
+			{
+			  $$.stoken = $1;
+			  $$.sym = lookup_symbol ($1.ptr,
+						  expression_context_block,
+						  VAR_DOMAIN,
+						  &$$.is_a_field_of_this);
+			}
 	;
 
 %%
diff --git a/gdb/testsuite/gdb.cp/userdef.cc b/gdb/testsuite/gdb.cp/userdef.cc
index 338c58a..56a735f 100644
--- a/gdb/testsuite/gdb.cp/userdef.cc
+++ b/gdb/testsuite/gdb.cp/userdef.cc
@@ -311,6 +311,11 @@ public:
   int z;
 };
 
+bool operator== (const Member &m1, const Member &m2)
+{
+  return m1.z == m2.z;
+}
+
 class Container
 {
 public:
@@ -330,8 +335,12 @@ int main (void)
  A1 two(4,5);
  A1 three(0,0);
  Container c;
+ Member mem1, mem2;
  int val;
  
+ mem1.z = 5;
+ mem2.z = 7;
+
  marker1(); // marker1-returns-here
  cout << one; // marker1-returns-here
  cout << two;
diff --git a/gdb/testsuite/gdb.cp/userdef.exp b/gdb/testsuite/gdb.cp/userdef.exp
index bd54c78..27ec80b 100644
--- a/gdb/testsuite/gdb.cp/userdef.exp
+++ b/gdb/testsuite/gdb.cp/userdef.exp
@@ -113,6 +113,7 @@ gdb_test "print one > two" "\\\$\[0-9\]* = 0\[\r\n\]"
 gdb_test "print one >= two" "\\\$\[0-9\]* = 0\[\r\n\]"
 
 gdb_test "print one == two" "\\\$\[0-9\]* = 0\[\r\n\]"
+gdb_test "print one.operator== (two)" "\\\$\[0-9\]* = 0\[\r\n\]"
 
 gdb_test "print one != two" "\\\$\[0-9\]* = 1\[\r\n\]"
 
@@ -155,5 +156,8 @@ gdb_test "print *c" "\\\$\[0-9\]* = \\(Member &\\) @$hex: {z = .*}"
 gdb_test "print &*c" "\\\$\[0-9\]* = \\(Member \\*\\) $hex"
 gdb_test "ptype &*c" "type = struct Member {\[\r\n \]+int z;\[\r\n\]+} &\\*"
 
+gdb_test "print operator== (mem1, mem2)" " = false"
+gdb_test "print operator== (mem1, mem1)" " = true"
+
 gdb_exit
 return 0

Re: [expr-cumulative] RFA: fix explicit operator parsing

[Sami Wagiaalla]

On 01/27/2010 01:22 PM, Tom Tromey wrote:
> While looking at a bug I found that expr-cumulative does not handle one
> case of explicit calls to an operator:
>
>      (gdb) p operator==(s1,s2)
>      A syntax error in expression, near `operator==(s1,s2)'.
>
> The bug is that the name_not_typename production does not handle
> operator.
>
> This patch fixes the problem and adds a couple new test cases -- one for
> the bug and one for an explicit call to an operator as a member
> function; I couldn't find one of these in the test suite.
>
> Built and regtested on x86-64 (compile farm).
> Ok?
>

Yes, please commit.

Re: [expr-cumulative] RFA: fix explicit operator parsing

[Tom Tromey]

>> (gdb) p operator==(s1,s2)
>> A syntax error in expression, near `operator==(s1,s2)'.

Sami> Yes, please commit.

Thanks, I've pushed this.

Tom