================
@@ -272,4 +272,66 @@ Interpreter::Visit(const UnaryOpNode *node) {
m_expr, "invalid ast: unexpected binary operator", node->GetLocation());
}
+llvm::Expected<lldb::ValueObjectSP>
+Interpreter::Visit(const MemberOfNode *node) {
+ Status error;
+ auto base_or_err = Evaluate(node->GetBase());
+ if (!base_or_err) {
+ return base_or_err;
+ }
+ lldb::ValueObjectSP base = *base_or_err;
+
+ // Perform basic type checking.
+ CompilerType base_type = base->GetCompilerType();
+ // When using an arrow, make sure the base is a pointer or array type.
+ // When using a period, make sure the base type is NOT a pointer type.
+ if (node->GetIsArrow() && !base_type.IsPointerType() &&
+ !base_type.IsArrayType()) {
----------------
labath wrote:
Because we want to let the values (and their type systems) decide whether they
are dereferencable or not. That's what we did for the implementation of the `*`
operator.
I could be convinced by the "status quo" argument, but this doesn't look like
an equivalent implementation to that (for one, you're adding support for
dereferencing arrays), which is why I want to turn this around: if `*` does not
check for types, then why should `->` (which is defined as `(*x).`) do that?
What I can imagine is doing something on the error handling path -- if
dereferencing failed, we look at the value to provide a better error message
about why it failed. However, even in this case, I'd try to avoid looking at
the type too much and instead try to reuse the error message from the
Dereference operation (changing it, if needed) so that we can be sure it makes
sense regardless of how the value depends to implement dereferencing.
https://github.com/llvm/llvm-project/pull/138093
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
