[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"
----------------
labath wrote:

Okay, so could one say that it's usage is similar to the code in [CPlusPlusNameParser](https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusNameParser.cpp), which uses clang to tokenize the (function) name, but then does the parsing itself? Or does it go deeper than that?

The thing I'm thinking about is that "having all of the tokens defined" may not be such an advantage if we later add some features from other languages (I don't know, let's say the `?.` operator from Swift). For lexing, that may not matter cause you could maybe lex `?` and `.` separately and then join them later, but if it's doing more, then that may be a problem..

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