[Lldb-commits] [lldb] [lldb][test] Disable MD5 test for old versions of Visual Studio (PR #94325)

2024-06-04 Thread Vassil Vassilev via lldb-commits

https://github.com/vgvassilev updated 
https://github.com/llvm/llvm-project/pull/94325

>From 125112e5864affd45a016a0870a40d2b4f516732 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Tue, 4 Jun 2024 09:32:22 +
Subject: [PATCH 1/2] [lldb][test] Disable MD5 test for old versions of Visual
 Studio

In older versions there is this problem:
https://developercommunity.visualstudio.com/t/c-shared-state-futuresstate-default-constructs-the/60897

Which prevents us making a future out of a result type. There's
no good workaround so just don't compile this for older versions.
---
 .../Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp  | 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp 
b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
index 24111396b0ac6..7e95b16308321 100644
--- a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
+++ b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
@@ -593,6 +593,10 @@ TEST_F(GDBRemoteCommunicationClientTest, WriteMemoryTags) {
  "E03", false);
 }
 
+// Prior to this verison, constructing a std::future for a type without a
+// default constructor is not possible.
+// 
https://developercommunity.visualstudio.com/t/c-shared-state-futuresstate-default-constructs-the/60897
+#if _MSC_VER >= 1932
 TEST_F(GDBRemoteCommunicationClientTest, CalculateMD5) {
   FileSpec file_spec("/foo/bar", FileSpec::Style::posix);
   std::future> async_result = std::async(
@@ -614,3 +618,4 @@ TEST_F(GDBRemoteCommunicationClientTest, CalculateMD5) {
   EXPECT_EQ(expected_low, result->low());
   EXPECT_EQ(expected_high, result->high());
 }
+#endif

>From c790d42ea4fdf6c75cef04504c4366dc9572743b Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Tue, 4 Jun 2024 13:55:00 +
Subject: [PATCH 2/2] Check for non-msvc compilers

---
 .../Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp 
b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
index 7e95b16308321..11e14f9472164 100644
--- a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
+++ b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
@@ -596,7 +596,7 @@ TEST_F(GDBRemoteCommunicationClientTest, WriteMemoryTags) {
 // Prior to this verison, constructing a std::future for a type without a
 // default constructor is not possible.
 // 
https://developercommunity.visualstudio.com/t/c-shared-state-futuresstate-default-constructs-the/60897
-#if _MSC_VER >= 1932
+#if !defined(_MSC_VER) || _MSC_VER >= 1932
 TEST_F(GDBRemoteCommunicationClientTest, CalculateMD5) {
   FileSpec file_spec("/foo/bar", FileSpec::Style::posix);
   std::future> async_result = std::async(

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Revert "[lldb] Fix the way we set up the lldb modules infrastructure." (PR #66271)

2023-09-13 Thread Vassil Vassilev via lldb-commits

vgvassilev wrote:

@bnbarham, I think it would be useful to keep it. 

> If we think this is useful to keep I'll need to look into how 
> https://github.com/llvm/llvm-project/pull/65683 broke LLDB testing:

Incremental processing should also enable the llvm expression parser workflows. 
The advantage is that now we can write tests against `clang-repl` which 
combines the clang frontend and the llvm jit. If we capture the lldb workflows 
in these tests we will reduce the amount of regressions that inadvertently 
happen because of these two components are not tested together. 

> That change should effectively be NFC as far as -fincremental-extensions is 
> concerned, so if you have any ideas that would be appreciated :)

If you can provide links to the failing tests I can take a look.



https://github.com/llvm/llvm-project/pull/66271
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Revert "[lldb] Fix the way we set up the lldb modules infrastructure." (PR #66271)

2023-09-13 Thread Vassil Vassilev via lldb-commits

vgvassilev wrote:

Does that PR fix the tests you mentioned?

https://github.com/llvm/llvm-project/pull/66271
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] c95a0c9 - [lldb] Fix the way we set up the lldb modules infrastructure.

2022-12-04 Thread Vassil Vassilev via lldb-commits

Author: Vassil Vassilev
Date: 2022-12-05T07:39:19Z
New Revision: c95a0c91c0de66eb1066f23c69332522656f188e

URL: 
https://github.com/llvm/llvm-project/commit/c95a0c91c0de66eb1066f23c69332522656f188e
DIFF: 
https://github.com/llvm/llvm-project/commit/c95a0c91c0de66eb1066f23c69332522656f188e.diff

LOG: [lldb] Fix the way we set up the lldb modules infrastructure.

D127284 introduced a new language option which is not benign from modules
perspective. Before this patch lldb would set up the compiler invocation and
later enable incremental processing. Post-D127284 this does not work because
the option causes a module hash mismatch for implicit modules.

In addition, D127284 enables parsing statements on the global scope if
incremental processing is on and thus `syntax_error_for_lldb_to_find` was
rightfully not recognized as a declaration and is considered a statement
which produces a slightly different diagnostic.

Thanks to Michael Buch for the help in understanding this issue. This patch
should appease the lldb bots.

More discussion available at: https://reviews.llvm.org/D127284

Added: 


Modified: 
lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
lldb/test/API/lang/objc/modules-compile-error/TestModulesCompileError.py

Removed: 




diff  --git 
a/lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp 
b/lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
index ec4e9f12fc974..eea21f3f05fc9 100644
--- a/lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
+++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
@@ -609,7 +609,8 @@ ClangModulesDeclVendor::Create(Target &target) {
   "-target",
   arch.GetTriple().str(),
   "-fmodules-validate-system-headers",
-  "-Werror=non-modular-include-in-framework-module"};
+  "-Werror=non-modular-include-in-framework-module",
+  "-Xclang=-fincremental-extensions"};
 
   target.GetPlatform()->AddClangModuleCompilationOptions(
   &target, compiler_invocation_arguments);
@@ -701,8 +702,6 @@ ClangModulesDeclVendor::Create(Target &target) {
instance->getFrontendOpts().Inputs[0]))
 return nullptr;
 
-  instance->getPreprocessor().enableIncrementalProcessing();
-
   instance->createASTReader();
 
   instance->createSema(action->getTranslationUnitKind(), nullptr);

diff  --git 
a/lldb/test/API/lang/objc/modules-compile-error/TestModulesCompileError.py 
b/lldb/test/API/lang/objc/modules-compile-error/TestModulesCompileError.py
index 9a5cb257601da..45296ab4bf035 100644
--- a/lldb/test/API/lang/objc/modules-compile-error/TestModulesCompileError.py
+++ b/lldb/test/API/lang/objc/modules-compile-error/TestModulesCompileError.py
@@ -16,6 +16,6 @@ def test(self):
 # Check that the error message shows file/line/column, prints the 
relevant
 # line from the source code and mentions the module that failed to 
build.
 self.expect("expr @import LLDBTestModule", error=True,
-substrs=["module.h:4:1: error: unknown type name 
'syntax_error_for_lldb_to_find'",
+substrs=["module.h:4:1: error: undeclared identifier 
'syntax_error_for_lldb_to_find'",
  "syntax_error_for_lldb_to_find // comment that 
tests source printing",
  "could not build module 'LLDBTestModule'"])



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 03a3f86 - [lldb] Fix compilation by adjusting to the new ASTContext signature.

2021-07-11 Thread Vassil Vassilev via lldb-commits

Author: Vassil Vassilev
Date: 2021-07-11T10:53:36Z
New Revision: 03a3f86071c10a1f6cbbf7375aa6fe9d94168972

URL: 
https://github.com/llvm/llvm-project/commit/03a3f86071c10a1f6cbbf7375aa6fe9d94168972
DIFF: 
https://github.com/llvm/llvm-project/commit/03a3f86071c10a1f6cbbf7375aa6fe9d94168972.diff

LOG: [lldb] Fix compilation by adjusting to the new ASTContext signature.

This change was introduced in https://reviews.llvm.org/D104918

Added: 


Modified: 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Removed: 




diff  --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 306573e06250e..137cba40e1d65 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -746,7 +746,7 @@ void TypeSystemClang::CreateASTContext() {
   *m_diagnostics_engine_up, *m_file_manager_up);
   m_ast_up = std::make_unique(
   *m_language_options_up, *m_source_manager_up, *m_identifier_table_up,
-  *m_selector_table_up, *m_builtins_up);
+  *m_selector_table_up, *m_builtins_up, TU_Complete);
 
   m_diagnostic_consumer_up = std::make_unique();
   m_ast_up->getDiagnostics().setClient(m_diagnostic_consumer_up.get(), false);



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 5922f23 - Revert "[clang-repl] Implement partial translation units and error recovery."

2021-07-11 Thread Vassil Vassilev via lldb-commits

Author: Vassil Vassilev
Date: 2021-07-11T14:40:10Z
New Revision: 5922f234c8c95f61534160a31db15dfc10da9b60

URL: 
https://github.com/llvm/llvm-project/commit/5922f234c8c95f61534160a31db15dfc10da9b60
DIFF: 
https://github.com/llvm/llvm-project/commit/5922f234c8c95f61534160a31db15dfc10da9b60.diff

LOG: Revert "[clang-repl] Implement partial translation units and error 
recovery."

This reverts commit 6775fc6ffa3ca1c36b20c25fa4e7f48f81213cf2.

It also reverts "[lldb] Fix compilation by adjusting to the new ASTContext 
signature."

This reverts commit 03a3f86071c10a1f6cbbf7375aa6fe9d94168972.

We see some failures on the lldb infrastructure, these changes might play a role
in it. Let's revert it now and see if the bots will become green.

Ref: https://reviews.llvm.org/D104918

Added: 
clang/include/clang/Interpreter/Transaction.h

Modified: 
clang/include/clang/AST/ASTContext.h
clang/include/clang/AST/Decl.h
clang/include/clang/AST/Redeclarable.h
clang/include/clang/Basic/LangOptions.h
clang/include/clang/Interpreter/Interpreter.h
clang/include/clang/Lex/Preprocessor.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/ASTContext.cpp
clang/lib/AST/Decl.cpp
clang/lib/AST/DeclBase.cpp
clang/lib/Frontend/ASTUnit.cpp
clang/lib/Frontend/CompilerInstance.cpp
clang/lib/Interpreter/IncrementalParser.cpp
clang/lib/Interpreter/IncrementalParser.h
clang/lib/Interpreter/Interpreter.cpp
clang/lib/Sema/Sema.cpp
clang/lib/Serialization/ASTReader.cpp
clang/tools/clang-import-test/clang-import-test.cpp
clang/unittests/AST/ASTVectorTest.cpp
clang/unittests/Interpreter/IncrementalProcessingTest.cpp
clang/unittests/Interpreter/InterpreterTest.cpp
clang/unittests/Lex/PPCallbacksTest.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Removed: 
clang/include/clang/Interpreter/PartialTranslationUnit.h



diff  --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index 34299581d89d4..5032f3194a9b7 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -459,7 +459,6 @@ class ASTContext : public RefCountedBase {
   friend class ASTWriter;
   template  friend class serialization::AbstractTypeReader;
   friend class CXXRecordDecl;
-  friend class IncrementalParser;
 
   /// A mapping to contain the template or declaration that
   /// a variable declaration describes or was instantiated from,
@@ -568,7 +567,7 @@ class ASTContext : public RefCountedBase {
   ImportDecl *FirstLocalImport = nullptr;
   ImportDecl *LastLocalImport = nullptr;
 
-  TranslationUnitDecl *TUDecl = nullptr;
+  TranslationUnitDecl *TUDecl;
   mutable ExternCContextDecl *ExternCContext = nullptr;
   mutable BuiltinTemplateDecl *MakeIntegerSeqDecl = nullptr;
   mutable BuiltinTemplateDecl *TypePackElementDecl = nullptr;
@@ -625,7 +624,6 @@ class ASTContext : public RefCountedBase {
   IdentifierTable &Idents;
   SelectorTable &Selectors;
   Builtin::Context &BuiltinInfo;
-  const TranslationUnitKind TUKind;
   mutable DeclarationNameTable DeclarationNames;
   IntrusiveRefCntPtr ExternalSource;
   ASTMutationListener *Listener = nullptr;
@@ -1024,18 +1022,7 @@ class ASTContext : public RefCountedBase {
   /// Get the initializations to perform when importing a module, if any.
   ArrayRef getModuleInitializers(Module *M);
 
-  TranslationUnitDecl *getTranslationUnitDecl() const {
-return TUDecl->getMostRecentDecl();
-  }
-  void addTranslationUnitDecl() {
-assert(!TUDecl || TUKind == TU_Incremental);
-TranslationUnitDecl *NewTUDecl = TranslationUnitDecl::Create(*this);
-if (TraversalScope.empty() || TraversalScope.back() == TUDecl)
-  TraversalScope = {NewTUDecl};
-if (TUDecl)
-  NewTUDecl->setPreviousDecl(TUDecl);
-TUDecl = NewTUDecl;
-  }
+  TranslationUnitDecl *getTranslationUnitDecl() const { return TUDecl; }
 
   ExternCContextDecl *getExternCContextDecl() const;
   BuiltinTemplateDecl *getMakeIntegerSeqDecl() const;
@@ -1112,8 +1099,7 @@ class ASTContext : public RefCountedBase {
   llvm::DenseSet CUDADeviceVarODRUsedByHost;
 
   ASTContext(LangOptions &LOpts, SourceManager &SM, IdentifierTable &idents,
- SelectorTable &sels, Builtin::Context &builtins,
- TranslationUnitKind TUKind);
+ SelectorTable &sels, Builtin::Context &builtins);
   ASTContext(const ASTContext &) = delete;
   ASTContext &operator=(const ASTContext &) = delete;
   ~ASTContext();

diff  --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index 510bf89789851..d22594ae8442a 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -79,23 +79,7 @@ class UnresolvedSetImpl;
 class VarTemplateDecl;
 
 /// The top declaration context.
-class TranslationUnitDecl : public Decl,
-public DeclContext,
-   

[Lldb-commits] [lldb] 11b47c1 - Reland "[clang-repl] Implement partial translation units and error recovery."

2021-07-12 Thread Vassil Vassilev via lldb-commits

Author: Vassil Vassilev
Date: 2021-07-12T15:21:22Z
New Revision: 11b47c103a36371576711cae1f7527c26f78efb5

URL: 
https://github.com/llvm/llvm-project/commit/11b47c103a36371576711cae1f7527c26f78efb5
DIFF: 
https://github.com/llvm/llvm-project/commit/11b47c103a36371576711cae1f7527c26f78efb5.diff

LOG: Reland "[clang-repl] Implement partial translation units and error 
recovery."

Original commit message:

[clang-repl] Implement partial translation units and error recovery.

https://reviews.llvm.org/D96033 contained a discussion regarding efficient
modeling of error recovery. @rjmccall has outlined the key ideas:

Conceptually, we can split the translation unit into a sequence of partial
translation units (PTUs). Every declaration will be associated with a unique PTU
that owns it.

The first key insight here is that the owning PTU isn't always the "active"
(most recent) PTU, and it isn't always the PTU that the declaration
"comes from". A new declaration (that isn't a redeclaration or specialization of
anything) does belong to the active PTU. A template specialization, however,
belongs to the most recent PTU of all the declarations in its signature - mostly
that means that it can be pulled into a more recent PTU by its template
arguments.

The second key insight is that processing a PTU might extend an earlier PTU.
Rolling back the later PTU shouldn't throw that extension away. For example, if
the second PTU defines a template, and the third PTU requires that template to
be instantiated at float, that template specialization is still part of the
second PTU. Similarly, if the fifth PTU uses an inline function belonging to the
fourth, that definition still belongs to the fourth. When we go to emit code in
a new PTU, we map each declaration we have to emit back to its owning PTU and
emit it in a new module for just the extensions to that PTU. We keep track of
all the modules we've emitted for a PTU so that we can unload them all if we
decide to roll it back.

Most declarations/definitions will only refer to entities from the same or
earlier PTUs. However, it is possible (primarily by defining a
previously-declared entity, but also through templates or ADL) for an entity
that belongs to one PTU to refer to something from a later PTU. We will have to
keep track of this and prevent unwinding to later PTU when we recognize it.
Fortunately, this should be very rare; and crucially, we don't have to do the
bookkeeping for this if we've only got one PTU, e.g. in normal compilation.
Otherwise, PTUs after the first just need to record enough metadata to be able
to revert any changes they've made to declarations belonging to earlier PTUs,
e.g. to redeclaration chains or template specialization lists.

It should even eventually be possible for PTUs to provide their own slab
allocators which can be thrown away as part of rolling back the PTU. We can
maintain a notion of the active allocator and allocate things like Stmt/Expr
nodes in it, temporarily changing it to the appropriate PTU whenever we go to do
something like instantiate a function template. More care will be required when
allocating declarations and types, though.

We would want the PTU to be efficiently recoverable from a Decl; I'm not sure
how best to do that. An easy option that would cover most declarations would be
to make multiple TranslationUnitDecls and parent the declarations appropriately,
but I don't think that's good enough for things like member function templates,
since an instantiation of that would still be parented by its original class.
Maybe we can work this into the DC chain somehow, like how lexical DCs are.

We add a different kind of translation unit `TU_Incremental` which is a
complete translation unit that we might nonetheless incrementally extend later.
Because it is complete (and we might want to generate code for it), we do
perform template instantiation, but because it might be extended later, we don't
warn if it declares or uses undefined internal-linkage symbols.

This patch teaches clang-repl how to recover from errors by disconnecting the
most recent PTU and update the primary PTU lookup tables. For instance:

```./clang-repl
clang-repl> int i = 12; error;
In file included from <<< inputs >>>:1:
input_line_0:1:13: error: C++ requires a type specifier for all declarations
int i = 12; error;
^
error: Parsing failed.
clang-repl> int i = 13; extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=13
clang-repl> quit
```

Differential revision: https://reviews.llvm.org/D104918

Added: 
clang/include/clang/Interpreter/PartialTranslationUnit.h

Modified: 
clang/include/clang/AST/ASTContext.h
clang/include/clang/AST/Decl.h
clang/include/clang/AST/Redeclarable.h
clang/include/clang/Basic/LangOptions.h
clang/include/clang/Interpreter/Interpreter.h
clang/include/clang/Lex/Preprocessor.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/ASTContext.cpp
clang/lib/AST/D

[Lldb-commits] [lldb] [llvm] [DebugInfo] Add explicit visibility macros to CodeView template functions (PR #113102)

2024-10-22 Thread Vassil Vassilev via lldb-commits

https://github.com/vgvassilev updated 
https://github.com/llvm/llvm-project/pull/113102

>From 1001412f5d48385cf2e7489e44ea7b6b08e65258 Mon Sep 17 00:00:00 2001
From: Thomas Fransham 
Date: Mon, 12 Aug 2024 16:04:12 +0100
Subject: [PATCH 1/2] [DebugInfo] Add explicit visibility macros to CodeView
 template functions

These will be needed for when llvm is built as a shared library on windows with
explicit visibility macros enabled.
Change UnionRecord to class instead of a struct so we can use X macros from
CodeViewTypes.def to forward declare all record classes.

This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and LLVM plugins on 
window.
---
 .../SymbolFile/NativePDB/SymbolFileNativePDB.h |  2 +-
 .../DebugInfo/CodeView/ContinuationRecordBuilder.h | 14 ++
 .../llvm/DebugInfo/CodeView/SimpleTypeSerializer.h | 13 +
 llvm/include/llvm/DebugInfo/CodeView/TypeRecord.h  |  3 ++-
 4 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h 
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
index 669c44aa131edc..297f11451afb75 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
@@ -32,7 +32,7 @@ class ClassRecord;
 class EnumRecord;
 class ModifierRecord;
 class PointerRecord;
-struct UnionRecord;
+class UnionRecord;
 } // namespace codeview
 } // namespace llvm
 
diff --git a/llvm/include/llvm/DebugInfo/CodeView/ContinuationRecordBuilder.h 
b/llvm/include/llvm/DebugInfo/CodeView/ContinuationRecordBuilder.h
index 84cef520a2f460..8347ef870d0676 100644
--- a/llvm/include/llvm/DebugInfo/CodeView/ContinuationRecordBuilder.h
+++ b/llvm/include/llvm/DebugInfo/CodeView/ContinuationRecordBuilder.h
@@ -50,6 +50,20 @@ class ContinuationRecordBuilder {
 
   std::vector end(TypeIndex Index);
 };
+
+// Needed by RandomAccessVisitorTest.cpp
+#define TYPE_RECORD(EnumName, EnumVal, Name)
+#define TYPE_RECORD_ALIAS(EnumName, EnumVal, Name, AliasName)
+#define MEMBER_RECORD(EnumName, EnumVal, Name) 
\
+  extern template LLVM_TEMPLATE_ABI void 
ContinuationRecordBuilder::writeMemberType(\
+  Name##Record &Record);
+#define MEMBER_RECORD_ALIAS(EnumName, EnumVal, Name, AliasName)
+#include "llvm/DebugInfo/CodeView/CodeViewTypes.def"
+#undef TYPE_RECORD
+#undef TYPE_RECORD_ALIAS
+#undef MEMBER_RECORD
+#undef MEMBER_RECORD_ALIAS
+
 } // namespace codeview
 } // namespace llvm
 
diff --git a/llvm/include/llvm/DebugInfo/CodeView/SimpleTypeSerializer.h 
b/llvm/include/llvm/DebugInfo/CodeView/SimpleTypeSerializer.h
index fcc0452a6ae9a7..713798fc38d2d8 100644
--- a/llvm/include/llvm/DebugInfo/CodeView/SimpleTypeSerializer.h
+++ b/llvm/include/llvm/DebugInfo/CodeView/SimpleTypeSerializer.h
@@ -32,6 +32,19 @@ class SimpleTypeSerializer {
   ArrayRef serialize(const FieldListRecord &Record) = delete;
 };
 
+// Needed by RandomAccessVisitorTest.cpp
+#define TYPE_RECORD(EnumName, EnumVal, Name)   
\
+  class Name##Record;  
\
+  extern template LLVM_TEMPLATE_ABI ArrayRef 
llvm::codeview::SimpleTypeSerializer::serialize(  \
+  Name##Record &Record);
+#define TYPE_RECORD_ALIAS(EnumName, EnumVal, Name, AliasName)
+#define MEMBER_RECORD(EnumName, EnumVal, Name)
+#define MEMBER_RECORD_ALIAS(EnumName, EnumVal, Name, AliasName)
+#include "llvm/DebugInfo/CodeView/CodeViewTypes.def"
+#undef TYPE_RECORD
+#undef TYPE_RECORD_ALIAS
+#undef MEMBER_RECORD
+#undef MEMBER_RECORD_ALIAS
 } // end namespace codeview
 } // end namespace llvm
 
diff --git a/llvm/include/llvm/DebugInfo/CodeView/TypeRecord.h 
b/llvm/include/llvm/DebugInfo/CodeView/TypeRecord.h
index 5a84fac5f59034..484e05b5adc672 100644
--- a/llvm/include/llvm/DebugInfo/CodeView/TypeRecord.h
+++ b/llvm/include/llvm/DebugInfo/CodeView/TypeRecord.h
@@ -495,7 +495,8 @@ class ClassRecord : public TagRecord {
 };
 
 // LF_UNION
-struct UnionRecord : public TagRecord {
+class UnionRecord : public TagRecord {
+public:
   UnionRecord() = default;
   explicit UnionRecord(TypeRecordKind Kind) : TagRecord(Kind) {}
   UnionRecord(uint16_t MemberCount, ClassOptions Options, TypeIndex FieldList,

>From d9de70aab0258f652be5803c1ed24b3c0f348cf2 Mon Sep 17 00:00:00 2001
From: Thomas Fransham 
Date: Sun, 20 Oct 2024 20:35:48 +0100
Subject: [PATCH 2/2] Fix formatting

---
 .../llvm/DebugInfo/CodeView/ContinuationRecordBuilder.h   | 4 ++--
 llvm/include/llvm/DebugInfo/CodeView/SimpleTypeSerializer.h   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/llvm/include/llvm/DebugInfo/CodeView/ContinuationRecordBuilder.h 
b/llvm/include/llvm/DebugInfo/CodeView/ContinuationRecordBuilder.h
index 8347ef870d0676..3de138f37be2d2 100644
--- a/llvm/include/llvm/DebugInfo/CodeView/ContinuationRecordBuilder.h
+++ b/llvm/include/llvm/DebugInfo/CodeView/ContinuationRecordBuil

[Lldb-commits] [lldb] [llvm] [DebugInfo] Add explicit visibility macros to CodeView template functions (PR #113102)

2024-11-02 Thread Vassil Vassilev via lldb-commits

vgvassilev wrote:

> The lldb change looks good (you can submit that in its own patch without a 
> review), but you'll probably want to find a different reviewer for the 
> codeview part (I have no idea who's responsible for that these days).

Thank you, maybe @adrian-prantl will know?

https://github.com/llvm/llvm-project/pull/113102
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [llvm] [DebugInfo] Add explicit visibility macros to CodeView template functions (PR #113102)

2024-10-28 Thread Vassil Vassilev via lldb-commits

vgvassilev wrote:

@JDevlieghere, ping.

https://github.com/llvm/llvm-project/pull/113102
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [llvm] [DebugInfo] Add explicit visibility macros to CodeView template functions (PR #113102)

2024-11-15 Thread Vassil Vassilev via lldb-commits

vgvassilev wrote:

@zmodem, ping.

https://github.com/llvm/llvm-project/pull/113102
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [Serialization] Support loading template specializations lazily (PR #119333)

2024-12-11 Thread Vassil Vassilev via lldb-commits

vgvassilev wrote:

@ChuanqiXu9, can we insert a fix for windows?

https://github.com/llvm/llvm-project/pull/119333
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [llvm] [DebugInfo] Add explicit visibility macros to CodeView template functions (PR #113102)

2024-12-11 Thread Vassil Vassilev via lldb-commits

vgvassilev wrote:

@fsfod, can you address the comments?

https://github.com/llvm/llvm-project/pull/113102
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits