================
@@ -608,4 +608,16 @@ Interpreter::Visit(const BooleanLiteralNode *node) {
   return ValueObject::CreateValueObjectFromBool(m_target, value, "result");
 }
 
+llvm::Expected<lldb::ValueObjectSP>
+Interpreter::Visit(const CStyleCastNode *node) {
+  auto operand_or_err = Evaluate(node->GetOperand());
+  if (!operand_or_err)
+    return operand_or_err;
+
+  lldb::ValueObjectSP operand = *operand_or_err;
+  // Don't actually do the cast for now -- that code will be added later.
+  // For now just return the original operand, unchanged.
+  return operand;
----------------
kuilpd wrote:

> Even `dwim-print` requires context in this regard. After all, an -> access of 
> a value that has an -> overload is going to be different in dwim-print. That 
> command works for common cases but really does require the user to know what 
> they are doing, since there will be cases where both `frame var` and `expr` 
> return valid but different results.
> So it seems to me we should be careful of anything we say or do that confuses 
> the two.

I haven't really thought about that. We already replaced old `frame var` with 
DIL, which is fine for now since it has basically the same functionality, but 
will become more of a problem as we add more operators. Compared to 
`dwim-print`, lldb-dap doesn't do any checks and just tries to use `frame var` 
for expressions, which means this was an existing problem when a `->` appeared. 
Even with the old implementation, the overloaded operator wouldn't be used.

I guess we'll have to think again if this was a correct approach to replace 
`frame var`, or if we should just add the same guards `dwim-print` does to 
lldb-dap. But I personally really hoped this would just speed up expression 
evaluation for everyone.

Also, in DIL we could potentially implement overloaded operators, at least with 
ABI calls, I don't know how limited or accurate this would be though.

https://github.com/llvm/llvm-project/pull/165199
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to