================
@@ -18,6 +18,22 @@
namespace lldb_private::dil {
+static lldb::ValueObjectSP
+ArrayToPointerConversion(lldb::ValueObjectSP valobj,
+ std::shared_ptr<ExecutionContextScope> ctx) {
+ assert(valobj->IsArrayType() &&
+ "an argument to array-to-pointer conversion must be an array");
+
+ uint64_t addr = valobj->GetLoadAddress();
+ llvm::StringRef name = "result";
+ ExecutionContext exe_ctx;
+ ctx->CalculateExecutionContext(exe_ctx);
+ return ValueObject::CreateValueObjectFromAddress(
+ name, addr, exe_ctx,
+
valobj->GetCompilerType().GetArrayElementType(ctx.get()).GetPointerType(),
+ /* do_deref */ false);
+}
+
----------------
jimingham wrote:
Yes, I concur. As a general rule, we want the evaluator to know as little as
possible about how any operation is performed and delegate as much as possible
to ValueObject methods.
The evaluator can't know anything about the language of the values it is
operating on or it will either only work for C-backed ValueObjects or end up
cluttered with "if C/C++/swift/go/future_language" code, which we really want
to avoid. However, ValueObjects always know what type system their type comes
from, and so they can naturally do the right thing for their language. So we
should defer to them whenever we're doing any non-trivial operations.
https://github.com/llvm/llvm-project/pull/134428
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
