Michael137 wrote:
> The correct answer here is probably to fix the sizes in the RecordLayout
> itself; in particular, the DataSize of the members.
That would be ideal, but also means we'd have to reflect the various C++
attributes that affect layout in DWARF. Avoiding adding such
https://github.com/Michael137 approved this pull request.
Lets do the cleanup of `IsClassOrStruct` as a follow-up since there seem quite
a few places that could benefit from it
https://github.com/llvm/llvm-project/pull/93839
___
lldb-commits mailing
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/93839
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -13,12 +13,18 @@
using namespace lldb_private::dwarf;
using namespace lldb_private::plugin::dwarf;
+static bool IsStructOrClassTag(llvm::dwarf::Tag Tag) {
Michael137 wrote:
There's also
```
/// Returns true if `tag` is a class_type of structure_type tag.
@@ -2232,6 +2232,10 @@ bool DWARFASTParserClang::CompleteRecordType(const
DWARFDIE ,
// For objective C we don't start the definition when the class is
// created.
TypeSystemClang::StartTagDeclarationDefinition(clang_type);
+} else {
+ assert(
+
@@ -13,12 +13,18 @@
using namespace lldb_private::dwarf;
using namespace lldb_private::plugin::dwarf;
+static bool IsStructOrClassTag(llvm::dwarf::Tag Tag) {
Michael137 wrote:
Are there more tag equality checks around LLDB that could benefit from re-using
@@ -2232,6 +2232,11 @@ bool DWARFASTParserClang::CompleteRecordType(const
DWARFDIE ,
// For objective C we don't start the definition when the class is
// created.
TypeSystemClang::StartTagDeclarationDefinition(clang_type);
+} else if
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/93839
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -2232,6 +2232,11 @@ bool DWARFASTParserClang::CompleteRecordType(const
DWARFDIE ,
// For objective C we don't start the definition when the class is
// created.
TypeSystemClang::StartTagDeclarationDefinition(clang_type);
+} else if
@@ -13,12 +13,18 @@
using namespace lldb_private::dwarf;
using namespace lldb_private::plugin::dwarf;
+static bool IsStructOrClassTag(llvm::dwarf::Tag Tag) {
Michael137 wrote:
Ah yes in `SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext` we have the
@@ -13,12 +13,18 @@
using namespace lldb_private::dwarf;
using namespace lldb_private::plugin::dwarf;
+static bool IsStructOrClassTag(llvm::dwarf::Tag Tag) {
Michael137 wrote:
I think we have this function somewhere already. Might be worth checking
https://github.com/Michael137 approved this pull request.
Can confirm that tests pass on my mac now
https://github.com/llvm/llvm-project/pull/93836
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
Michael137 wrote:
Looks like this is breaking the macOS CI:
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake/2534/execution/node/97/log
```
==
FAIL: test_shlib_name (TestCompletion.CommandLineCompletionTestCase)
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/93809
>From 91276f5b2dc05032a285b465c0c8a69541bb25c4 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Thu, 2 May 2024 09:05:01 +0100
Subject: [PATCH 1/3] [clang][lldb] Don't assert structure layout correctness
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/93809
>From 91276f5b2dc05032a285b465c0c8a69541bb25c4 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Thu, 2 May 2024 09:05:01 +0100
Subject: [PATCH 1/2] [clang][lldb] Don't assert structure layout correctness
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/93809
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/93809
This is the outcome of the discussions we had in
https://discourse.llvm.org/t/rfc-lldb-handling-no-unique-address-in-lldb/77483
To summarize, LLDB creates AST nodes by parsing debug-info and hands those off
Author: Michael Buch
Date: 2024-05-30T12:40:05+01:00
New Revision: 8b600a37325bd68c370b00838c9f0a0fda1af6ce
URL:
https://github.com/llvm/llvm-project/commit/8b600a37325bd68c370b00838c9f0a0fda1af6ce
DIFF:
https://github.com/llvm/llvm-project/commit/8b600a37325bd68c370b00838c9f0a0fda1af6ce.diff
Michael137 wrote:
I'll revert this for now. Let me know if you need help reproducing the failure
https://github.com/llvm/llvm-project/pull/92014
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
Michael137 wrote:
@clayborg this change went in as part of
https://github.com/llvm/llvm-project/pull/92328 so i think we can close this
now.
Though there's a test failure linked to that PR currently, meaning it might
have to get reverted. We should keep an eye out for that
Michael137 wrote:
Huh this is an interesting one. So it looks like we first parse and insert
`struct Inner` into `UniqueDWARFASTTypeMap` as a forward declaration. Then when
we search the debug-map for the definition of `Inner`, we find it declared as
`class Inner` (note, *class* vs.
https://github.com/Michael137 approved this pull request.
Seems like a reasonable thing to do (as this comment in [LoadAddressResolver
::Resolve](https://github.com/llvm/llvm-project/blob/fd8b2d2046508c027ccf0fffb50d665c8355997a/lldb/source/Expression/IRExecutionUnit.cpp#L758-L761)
implies).
Michael137 wrote:
Unfortunately this breaks `TestCPPAccelerator.py` on the macOS buildbots:
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/4788/execution/node/97/log/
```
Ran command:
"log enable dwarf lookups
Michael137 wrote:
FYI, the `TestAddressRange` tests are failing on the macOS buildbots:
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/4764/execution/node/97/log/
```
==
FAIL:
Author: Michael Buch
Date: 2024-05-29T16:20:42+01:00
New Revision: fe82a3da36196157c0caa1ef2505186782f750d1
URL:
https://github.com/llvm/llvm-project/commit/fe82a3da36196157c0caa1ef2505186782f750d1
DIFF:
https://github.com/llvm/llvm-project/commit/fe82a3da36196157c0caa1ef2505186782f750d1.diff
Michael137 wrote:
I'm going to revert this for now until since the bots have been red for a while
now
https://github.com/llvm/llvm-project/pull/92865
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://github.com/Michael137 approved this pull request.
https://github.com/llvm/llvm-project/pull/93675
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Michael137 wrote:
Now that we don't search for the definition DIE when initially parsing a DIE,
we could probably move this progress report to when we look for
`FindDefinitionTypeForDIE`, which seems to be the most expensive part of the
`DWARFASTParser`
Michael137 wrote:
@labath baseline for just attaching is approximately `3 s` for LLDB and `2.5
s`. Baselines for attaching *and* stopping at the breakpoint are in the `break
only` rows of the table.
https://github.com/llvm/llvm-project/pull/91452
https://github.com/Michael137 approved this pull request.
nice! tests also LGTM
https://github.com/llvm/llvm-project/pull/93291
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 approved this pull request.
LGTM!
(seems like we could probably add unit-tests for this in
`lldb/unittests/SymbolFile/DWARF/DWARFDIETest.cpp`? But not a blocker)
https://github.com/llvm/llvm-project/pull/93291
___
Michael137 wrote:
Sorry for the delayed response, just got back from vacation.
> What do these numbers include? Is it just the operation it self, or
> everything leading up to it as well.
> Thanks for doing this. What do these numbers include? Is it just the
> operation it self, or
Michael137 wrote:
I think we should just fix https://github.com/llvm/llvm-project/issues/92574
since it seems pretty trivial to do with an ifdef
https://github.com/llvm/llvm-project/pull/92575
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
Michael137 wrote:
I attached to clang and printed an expression. That resulted in 16801 calls to
`Progress::Increment`, all of which I'm guessing translate to event broadcasts.
I collected some timing numbers:
```
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/92328
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -321,6 +326,10 @@ class SymbolFileDWARFDebugMap : public SymbolFileCommon {
std::vector m_func_indexes; // Sorted by address
std::vector m_glob_indexes;
std::map>, OSOInfoSP>
m_oso_map;
+ // A map from CompilerType to the struct/class/union/enum DIE (might be a
+
@@ -2306,6 +2345,11 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const
DWARFDIE ,
if (!die)
return false;
+ ParsedDWARFTypeAttributes attrs(die);
Michael137 wrote:
I've been wondering how expensive constructing this object is. On a brief
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/91985
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/91985
>From 1ccf935f97b21e0bd87955f3313cb47261d11379 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 13 May 2024 15:34:24 +0100
Subject: [PATCH 1/3] [lldb][TypeSystem][NFCI] Log creation of new TypeSystem
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/91989
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/91989
>From 1fba045db76f51a2dbd9a2a3cb9879858b5b653e Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 13 May 2024 14:50:07 +0100
Subject: [PATCH 1/3] [lldb][ExpressionParser][NFCI] Log pointers as hex
This
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/91985
>From 1ccf935f97b21e0bd87955f3313cb47261d11379 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 13 May 2024 15:34:24 +0100
Subject: [PATCH 1/3] [lldb][TypeSystem][NFCI] Log creation of new TypeSystem
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/91985
>From 1ccf935f97b21e0bd87955f3313cb47261d11379 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 13 May 2024 15:34:24 +0100
Subject: [PATCH 1/2] [lldb][TypeSystem][NFCI] Log creation of new TypeSystem
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/91989
>From 1fba045db76f51a2dbd9a2a3cb9879858b5b653e Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 13 May 2024 14:50:07 +0100
Subject: [PATCH 1/2] [lldb][ExpressionParser][NFCI] Log pointers as hex
This
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/91989
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/91989
This ensures that we log pointers as lower-case hex. E.g., instead of:
```
LayoutRecordType on (ASTContext*)0x00010E78D600 'scratch ASTContext' for
(RecordDecl*)0x00010E797
```
we now log:
```
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/91985
We emit `ASTContext` and `TypeSystem` pointers into the `expr` log but there is
no easy way (that I know of) to correlate the pointer value back to an easily
readible form. This patch simply logs the name of
Michael137 wrote:
> I am somewhat worried about this slowing down the actual operations it is
> reporting progress on. I didn't really measure this, but intuitively, I'd
> expect that a one of these operations (parsing/importing one type) would be
> pretty fast, and that the whole process
https://github.com/Michael137 approved this pull request.
Looks much cleaner now, thanks!
https://github.com/llvm/llvm-project/pull/91586
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
@@ -492,12 +494,37 @@ class Type : public std::enable_shared_from_this,
public UserID {
static int Compare(const Type , const Type );
+ // Represents a parsed type name coming out of GetTypeScopeAndBasename. The
+ // structure holds StringRefs pointing to portions of
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/91586
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1411,3 +1414,35 @@ clang::Decl *
ClangASTImporter::ASTImporterDelegate::GetOriginalDecl(clang::Decl *To) {
return m_main.GetDeclOrigin(To).decl;
}
+
+void ClangASTImporter::ASTImporterDelegate::UpdateImportProgress(
+clang::Decl const *From) {
+ assert(From &&
+
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1411,3 +1414,35 @@ clang::Decl *
ClangASTImporter::ASTImporterDelegate::GetOriginalDecl(clang::Decl *To) {
return m_main.GetDeclOrigin(To).decl;
}
+
+void ClangASTImporter::ASTImporterDelegate::UpdateImportProgress(
Michael137 wrote:
These asserts
Michael137 wrote:
Example of what the DIE parsing progress looks like:
https://github.com/llvm/llvm-project/assets/14071464/bd589ddd-c933-4e14-a380-f4db177e33d4
https://github.com/llvm/llvm-project/pull/91452
___
lldb-commits mailing list
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/91452
This is an attempt at displaying the work that's being done by LLDB when
waiting on type-completion events, e.g., when running an expression. We add
three new progress reports (across three commits):
1. When
https://github.com/Michael137 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/91189
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 approved this pull request.
https://github.com/llvm/llvm-project/pull/91010
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/90960
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Michael137 wrote:
> > Is any of it testable?
>
> Good question. Though this is mostly meant to be "NFC" (with very large
> quotes), I can imagine us doing something like forcing the parsing of a
> specific type (`type lookup ` ?), and then checking that the
> module ast (`image dump ast`)
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -16,60 +16,65 @@ using namespace lldb_private::plugin::dwarf;
bool UniqueDWARFASTTypeList::Find(const DWARFDIE ,
const lldb_private::Declaration ,
const int32_t byte_size,
+
https://github.com/Michael137 commented:
The idea makes sense and I like that we could factor things out of
`ParseStructureLikeDIE`, so generally LGTM (module Pavel's comments). Is any of
it testable?
https://github.com/llvm/llvm-project/pull/90663
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/90663
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1664,13 +1793,40 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext ,
}
if (dwarf->GetUniqueDWARFASTTypeMap().Find(
-unique_typename, die, unique_decl, attrs.byte_size.value_or(-1),
-*unique_ast_entry_up)) {
+
https://github.com/Michael137 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/81355
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/90657
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/89981
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/89981
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1203,26 +1203,23 @@ bool StackFrame::IsArtificial() const {
return m_stack_frame_kind == StackFrame::Kind::Artificial;
}
-lldb::LanguageType StackFrame::GetLanguage() {
+SourceLanguage StackFrame::GetLanguage() {
CompileUnit *cu =
@@ -1156,6 +1159,10 @@ CompilerType
TypeSystemClang::GetTypeForDecl(ObjCInterfaceDecl *decl) {
return GetType(getASTContext().getObjCInterfaceType(decl));
}
+CompilerType TypeSystemClang::GetTypeForDecl(clang::ValueDecl *value_decl) {
Michael137 wrote:
@@ -107,6 +107,35 @@ class SBTypeMemberFunction {
lldb::TypeMemberFunctionImplSP m_opaque_sp;
};
+class LLDB_API SBTypeStaticField {
+public:
+ SBTypeStaticField();
+
+ SBTypeStaticField(const lldb::SBTypeStaticField );
+ lldb::SBTypeStaticField =(const
@@ -27,6 +27,7 @@ class Task {
enum E : unsigned char {} e;
union U {
} u;
+static constexpr long static_constexpr_field = 47;
Michael137 wrote:
Should we have an XFAIL test for the non-constant case?
@@ -9074,6 +9111,21 @@ CompilerType
TypeSystemClang::DeclGetFunctionArgumentType(void *opaque_decl,
return CompilerType();
}
+Scalar TypeSystemClang::DeclGetConstantValue(void *opaque_decl) {
+ clang::Decl *decl = static_cast(opaque_decl);
+ if (clang::VarDecl *var_decl
@@ -1156,6 +1159,10 @@ CompilerType
TypeSystemClang::GetTypeForDecl(ObjCInterfaceDecl *decl) {
return GetType(getASTContext().getObjCInterfaceType(decl));
}
+CompilerType TypeSystemClang::GetTypeForDecl(clang::ValueDecl *value_decl) {
Michael137 wrote:
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/89730
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 approved this pull request.
LGTM with some minor clarification questions/style comments
https://github.com/llvm/llvm-project/pull/89730
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://github.com/Michael137 approved this pull request.
https://github.com/llvm/llvm-project/pull/89427
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Michael137 wrote:
LGTM thanks for the cleanup!
https://github.com/llvm/llvm-project/pull/89427
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 approved this pull request.
https://github.com/llvm/llvm-project/pull/89183
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Michael137 wrote:
> > One thing I'd like to get feedback on is whether this should be looking
> > into base classes. The discussion on the original PR focuses on lexically
> > nested types, but going through base classes (following usual language
> > rules) is another form of nesting. Both
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/88724
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/88724
>From e85bf75077dec2d6aa7d6983bbde222d1c2b3f29 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 15 Apr 2024 10:37:05 +0100
Subject: [PATCH 1/2] [lldb][ClangExpressionDeclMap][NFC] Remove unused
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/88721
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/88721
>From f0b309c52a7f497aa021f38f3ce272a1bb3e66ea Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Mon, 15 Apr 2024 13:16:58 +0100
Subject: [PATCH] [lldb][TypeSystemClang][NFCI] Use
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/88703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/88724
This member was never actually used, ever since its introduction in
`ca4e0fd7e63b90e6f68044af47248c64f250ee8f`.
>From e85bf75077dec2d6aa7d6983bbde222d1c2b3f29 Mon Sep 17 00:00:00 2001
From: Michael Buch
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/88721
This logic was originally copied from `CompilerInstance::parseLangArgs`. Since
then, the `CompilerInstance` uses `LangOptions::setLangDefaults` to set up new
`LangOptions` instances. In our case, we only
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/88703
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/88703
Done for consistency with the rest of the enums in `lldb-enumerations.h`. See
https://github.com/llvm/llvm-project/pull/80167#issuecomment-2043721298
>From ba9d7105b334e3969e7f9f172cae37ea4f2f553e Mon Sep 17
https://github.com/Michael137 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/88613
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,194 @@
+//===--
LibCxxProxyArray.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:
Michael137 wrote:
Awesome, thanks for doing this!!
https://github.com/llvm/llvm-project/pull/88312
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/87807
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/87807
>From 734e127b758b00210aa508c84d0222165c036ac4 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Fri, 5 Apr 2024 12:10:09 +0100
Subject: [PATCH 1/2] [lldb][test] Add tests for evaluating local variables
https://github.com/Michael137 approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/88178
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1068,6 +1068,29 @@ static void
LoadLibCxxFormatters(lldb::TypeCategoryImplSP cpp_category_sp) {
eTypeOptionCascade,
true);
+ AddCXXSummary(
+ cpp_category_sp,
+
https://github.com/Michael137 updated
https://github.com/llvm/llvm-project/pull/87807
>From 734e127b758b00210aa508c84d0222165c036ac4 Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Fri, 5 Apr 2024 12:10:09 +0100
Subject: [PATCH] [lldb][test] Add tests for evaluating local variables whose
https://github.com/Michael137 closed
https://github.com/llvm/llvm-project/pull/87767
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
1 - 100 of 665 matches
Mail list logo
