[Lldb-commits] [lldb] [LLDB] Add type casting to DIL, part 1 of 3. (PR #165199)

[via lldb-commits]

================
@@ -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