[all-commits] [llvm/llvm-project] c6da2c: [lldb][Commands] Fix memory find for Swift express...

[Michael Buch via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c6da2c877cb407c0404e58c5ca257d12036ed164
      https://github.com/llvm/llvm-project/commit/c6da2c877cb407c0404e58c5ca257d12036ed164
  Author: Michael Buch <michaelbuch12 at gmail.com>
  Date:   2025-06-12 (Thu, 12 Jun 2025)

  Changed paths:
    M lldb/source/Commands/CommandObjectMemory.cpp

  Log Message:
  -----------
  [lldb][Commands] Fix memory find for Swift expressions (#143860)

(depends on https://github.com/llvm/llvm-project/pull/143686)

There were two issues previously preventing `memory find -e` expressions
to succeed when stopped in Swift frames:
1. We weren't getting the dynamic type of the result `ValueObject`.
   For Swift this would fail when we tried to produce a scalar value
   out of it because the static VO wasn't sufficient to get to the
integer value. Hence we add a call to
`GetQualifiedRepresentationIfAvailable`
(which is what we do for expressions in `OptionArgParser::ToAddress`
too).
2. We weren't passing an `ExecutionContextScope` to `GetByteSize`, which
   Swift relied on to get the size of the result type.

My plan is to add an API test for this on the Apple
`swiftlang/llvm-project` fork.

I considered an alternative where we use `OptionArgParser::ToAddress`
for `memory find -e` expressions, but it got a bit icky when trying to
figure out how many bytes we should copy out of the result into the
`DataBufferHeap` (currently we rely on the size of the result variable
type). This gets even trickier when we were to pass an expression that
was actually a hex digit or a number into `ToAddress`.

rdar://152113525



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications