================
@@ -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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to