================
@@ -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;
----------------
jimingham wrote:
I'm worried about this terminology. `frame var` is not and should not be
expression evaluation. It's for static inspection of memory, it doesn't do
operator overloads in general, and doesn't construct temporary objects or call
copy constructors or anything like that. It just looks at static values in
memory. We should not give the impression that `frame var` is the expression
evaluator.
This project started because some folks wanted to make it easier to write data
formatters (which should be non-code-running for efficiency & stability) using
"value path expressions" that required some operations we didn't support in the
`frame var` language. In that use case, presumably the authors know what they
are doing and won't confuse DIL with the real language specific expression
evaluator.
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 do that confuses the two.
https://github.com/llvm/llvm-project/pull/165199
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
