ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.
The header includes were updated with the following command:
```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```
28 lines
888 B
C++
28 lines
888 B
C++
//===-- ClangExpressionUtil.cpp -------------------------------------------===//
|
|
//
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#include "ClangExpressionUtil.h"
|
|
|
|
#include "lldb/Target/StackFrame.h"
|
|
#include "lldb/Utility/ConstString.h"
|
|
#include "lldb/ValueObject/ValueObject.h"
|
|
|
|
namespace lldb_private {
|
|
namespace ClangExpressionUtil {
|
|
lldb::ValueObjectSP GetLambdaValueObject(StackFrame *frame) {
|
|
assert(frame);
|
|
|
|
if (auto this_val_sp = frame->FindVariable(ConstString("this")))
|
|
if (this_val_sp->GetChildMemberWithName("this"))
|
|
return this_val_sp;
|
|
|
|
return nullptr;
|
|
}
|
|
} // namespace ClangExpressionUtil
|
|
} // namespace lldb_private
|