[Lldb-commits] [lldb] [LLDB] Add AST node classes, functions, etc. for Data Inspection Lang… (PR #95738)

[Pavel Labath via lldb-commits]

================
@@ -0,0 +1,459 @@
+//===-- DILAST.h ------------------------------------------------*- C++ -*-===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLDB_CORE_DILAST_H
+#define LLDB_CORE_DILAST_H
+
+#include <memory>
+#include <optional>
+#include <string>
+#include <variant>
+#include <vector>
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/Symbol/Type.h"
+#include "lldb/Symbol/TypeList.h"
+#include "lldb/Target/LanguageRuntime.h"
+#include "lldb/Utility/ConstString.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/TokenKinds.h"
+#include "llvm/ADT/APFloat.h"
+#include "llvm/ADT/APInt.h"
+#include "llvm/Support/Casting.h"
+
+namespace lldb_private {
+
+namespace DIL {
+
+/// Struct to hold information about member fields. Used by the parser for the
+/// Data Inspection Language (DIL).
+struct MemberInfo {
+  std::optional<std::string> name;
+  CompilerType type;
+  std::optional<uint32_t> bitfield_size_in_bits;
+  bool is_synthetic;
+  bool is_dynamic;
+  lldb::ValueObjectSP val_obj_sp;
+};
+
+/// Get the appropriate ValueObjectSP, consulting the use_dynamic and
+/// use_synthetic options passed, acquiring the process & target locks if
+/// appropriate.
+lldb::ValueObjectSP GetDynamicOrSyntheticValue(
+    lldb::ValueObjectSP valobj_sp,
+    lldb::DynamicValueType use_dynamic = lldb::eNoDynamicValues,
+    bool use_synthetic = false);
+
+/// The various types DIL AST nodes (used by the DIL parser).
+enum class NodeKind {
+  eErrorNode,
+  eScalarLiteralNode,
+  eStringLiteralNode,
+  eIdentifierNode,
+  eCStyleCastNode,
+  eMemberOfNode,
+  eArraySubscriptNode,
+  eUnaryOpNode,
+  eSmartPtrToPtrDecayNode
----------------
labath wrote:

Can we get rid of this as well (for the time being, at least)? It sounds like one of those things that may require rearchitecting to avoid smart pointer assumptions...

(And even we do end up adding it, I don't think it should be called "**smart pointer** decay", as, as far as this code is concerned, I think we shouldn't be making a difference between std::unique_ptr and say std::optional. I guess you could stretch the "smart pointer" definition to cover optionals, but that doesn't seem ideal)

https://github.com/llvm/llvm-project/pull/95738