Fix Rust parser bug with function fields

In Rust, 'obj.f()' is a method call -- but '(obj.f)()' is a call of a
function-valued field 'f' in 'obj'.  The Rust parser in gdb currently
gets this wrong.  This is PR rust/24082.

The expression and Rust parser rewrites made this simple to fix --
simply wrapping a parenthesized expression in a new operation handles
it.  This patch has a slight hack because I didn't want to introduce a
new exp_opcode enumeration constant just for this.  IMO this doesn't
matter, since we should work toward removing dependencies on these
opcodes anyway; but let me know what you think of this.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24082

1 files changed, 27 insertions, 0 deletions

diff --git a/gdb/rust-exp.h b/gdb/rust-exp.h
index 6a24f2c..778d87f 100644
--- a/gdb/rust-exp.h
+++ b/gdb/rust-exp.h
@@ -197,6 +197,33 @@ public:
   { return OP_AGGREGATE; }
 };
 
+/* Rust parenthesized operation.  This is needed to distinguish
+   between 'obj.f()', which is a method call, and '(obj.f)()', which
+   is a call of a function-valued field 'f'.  */
+class rust_parenthesized_operation
+  : public tuple_holding_operation<operation_up>
+{
+public:
+
+  explicit rust_parenthesized_operation (operation_up op)
+    : tuple_holding_operation (std::move (op))
+  {
+  }
+
+  value *evaluate (struct type *expect_type,
+		   struct expression *exp,
+		   enum noside noside) override
+  {
+    return std::get<0> (m_storage)->evaluate (expect_type, exp, noside);
+  }
+
+  enum exp_opcode opcode () const override
+  {
+    /* A lie but this isn't worth introducing a new opcode for.  */
+    return UNOP_PLUS;
+  }
+};
+
 } /* namespace expr */
 
 #endif /* RUST_EXP_H */