https://github.com/Endilll approved this pull request.
https://github.com/llvm/llvm-project/pull/94325
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Endilll wrote:
Yes, some try_compile checks where replaced with a check for
`CMAKE_CXX_COMPILER_ID`, so it's crucial for it to reflect the reality.
https://github.com/llvm/llvm-project/pull/92953
___
lldb-commits mailing list
https://github.com/Endilll approved this pull request.
https://github.com/llvm/llvm-project/pull/94220
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Endilll wrote:
> I've not been able to find what versioning scheme these 2 packages use, so
> I'm not sure what versions to put here if any.
>
> Currently Linaro has: psutil==5.9.4 on Windows psutil == 5.9.8 on Linux
> pexpect==4.9.0 on Linux
>
> I don't think it needs to be `==`, but maybe
Endilll wrote:
@vvereschaka Thank you for letting me know! I wonder how this got past our pre-
and post-commit CI, because we do build lldb with MSVC there. You fix makes
total sense, so I applied it.
https://github.com/llvm/llvm-project/pull/92953
Author: Vlad Serebrennikov
Date: 2024-06-01T12:48:12+03:00
New Revision: cd676e5b27cb985697deac052c797057f5a33c06
URL:
https://github.com/llvm/llvm-project/commit/cd676e5b27cb985697deac052c797057f5a33c06
DIFF:
Endilll wrote:
I think the issue is that we no longer passed `-fno-lifetime-dse` to GCC due to
incorrect condition (my fault), which caused some downstream LTO crashes as
reported by @mveriksson in
https://github.com/llvm/llvm-project/commit/4feae05c6abda364a9295aecfa600d7d4e7dfeb6#r142466703
Endilll wrote:
> FYI this causes a minor compile-time improvement in stage1 builds using gcc:
> https://llvm-compile-time-tracker.com/compare.php?from=32c3561d44aa792ef08d72b5a4c342c9965bc4c2=4feae05c6abda364a9295aecfa600d7d4e7dfeb6=instructions:u
> While that's nice, it does suggest that the
Endilll wrote:
Quite expectedly, I see buildbot failures. Working on them.
https://lab.llvm.org/buildbot/#/builders/36/builds/45836
https://lab.llvm.org/buildbot/#/builders/57/builds/35200
https://github.com/llvm/llvm-project/pull/92953
___
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/92953
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/92953
>From 66e05ac24613435dbe774d49684d8ff9d119c4c3 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 21 May 2024 21:41:24 +0300
Subject: [PATCH 1/3] Remove some `try_compile` CMake checks for compiler
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/92953
>From 66e05ac24613435dbe774d49684d8ff9d119c4c3 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 21 May 2024 21:41:24 +0300
Subject: [PATCH 1/2] Remove some `try_compile` CMake checks for compiler
Endilll wrote:
Here are CE links with the set of minimum required compilers that should cover
almost all the changes I made:
https://godbolt.org/z/j98xzhrGa
https://godbolt.org/z/errv4WhfP
https://godbolt.org/z/vnoh8YqEP
Windows-targeted flags were tested both on MSVC on CE, and on clang-cl 5.0
Endilll wrote:
On my setup, this patch improves CMake configuration times (from a clean state)
from 51 seconds down to 46 seconds (average of 3 measurements).
My setup: ancient x86 hardware, Debian Sid, nightly Clang, build directory on a
RAM disk. CMake invocation:
`cmake
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/92953
This patch remove 36 checks for compiler flags that are done via invoking the
compiler across LLVM, Clang, and LLDB. It's was made possible by raising the
bar for supported compilers that has been happening
Endilll wrote:
> For me the picture is limited to register printing. I'll be setting this new
> option on the register type when printing
>
Endilll wrote:
I'm excited so see changes in this area!
> It is a subset of https://github.com/llvm/llvm-project/pull/69815, only for
> use by register printing (ping @Endilll).
Yeah, that effort is stalled because I don't see a clear path forward there,
and I'm lacking energy to find and
Endilll wrote:
@Michael137 suggested that I check that performance of `FindDirectNestedType`
doesn't regress (at least for my use case), since I have custom instrumentation
in my formatter. I can confirm that 3 versions of this function (#68705,
#74786, and this PR) exhibit the same level of
Endilll 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 the existing
Author: Vlad Serebrennikov
Date: 2024-02-16T22:47:09+03:00
New Revision: 4214f25dccba36472c9666f1395eef894dca1bba
URL:
https://github.com/llvm/llvm-project/commit/4214f25dccba36472c9666f1395eef894dca1bba
DIFF:
Endilll wrote:
I'd appreciate if you gave me a slightly bit more time, because I've been
testing the fix locally in the meantime.
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
Endilll wrote:
@JDevlieghere I have an idea what have caused this failure, but I guess I have
to enable libcxx to replicate it locally.
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
Endilll wrote:
Trying to take a look, but https://green.lab.llvm.org is extraordinary slow for
me.
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll ready_for_review
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -150,6 +150,23 @@ def test(self):
invalid_type = task_type.FindDirectNestedType(None)
self.assertFalse(invalid_type)
+# Check that FindDirectNestedType works with types from AST
+pointer = frame0.FindVariable("pointer")
+pointer_type
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/81666
>From bf92dc89858668518a5d842eac34bdf1b3eaade2 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Wed, 14 Feb 2024 00:26:09 +0300
Subject: [PATCH 1/3] [lldb] Fix `FindDirectNestedType` not working with
Endilll wrote:
This PR is a draft because new test, which is simplified `llvm::PointerIntPair`
and `llvm::PointerIntPairInfo`, doesn't pass even with the proposed fix.
https://github.com/llvm/llvm-project/pull/81666
___
lldb-commits mailing list
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/81666
>From bf92dc89858668518a5d842eac34bdf1b3eaade2 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Wed, 14 Feb 2024 00:26:09 +0300
Subject: [PATCH 1/2] [lldb] Fix `FindDirectNestedType` not working with
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/81666
This patch attempts to fix lookup in class template specialization that have an
integral non-type template parameter of non-int type. unsigned 3 might be
printed as `3` or `3U` depending on PrintingPolicy. This
Endilll wrote:
> The logic is that this is a pretty big hole in our C++20 support and I don't
> think it's reasonable to try a merge after the deadline for 18. WDYT?
>From our past experience with release managers, they seem quite generous with
>deadlines to merge stuff in, as long as
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/77444
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Endilll wrote:
CI fails on formatting in unrelated files, so I'm going to ignore it:
```
t=1704988008448 + echo '*** Checking for trailing whitespace left in Clang
source files ***'
t=1704988008448 *** Checking for trailing whitespace left in Clang source files
***
t=1704988008448 + grep -rnI
@@ -25,7 +25,7 @@ template struct S {}; // #dr1801-S
S V; // #dr1801-S-i
// cxx98-14-error@-1 {{non-type template argument does not refer to any
declaration}}
// cxx98-14-note@#dr1801-S {{template parameter is declared here}}
-// since-cxx17-error@#dr1801-S-i {{non-type
https://github.com/Endilll commented:
C++ DR test changes look good to me.
https://github.com/llvm/llvm-project/pull/78041
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/78041
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -42,6 +42,28 @@ namespace dr1611 { // dr1611: dup 1658
C c;
}
+namespace dr1626 { // dr1626: no open
+// FIXME: current consensus for CWG2335 is that the examples are well-formed.
Endilll wrote:
We had an offline discussion, and concluded that this test
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/77444
>From 1cbf8eec15112cd6871fcfb69425c62f08c8f681 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 9 Jan 2024 14:17:21 +0300
Subject: [PATCH 1/4] [clang] Add tests for DRs about complete-class context
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/77444
>From 1cbf8eec15112cd6871fcfb69425c62f08c8f681 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 9 Jan 2024 14:17:21 +0300
Subject: [PATCH 1/4] [clang] Add tests for DRs about complete-class context
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/77444
>From 1cbf8eec15112cd6871fcfb69425c62f08c8f681 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 9 Jan 2024 14:17:21 +0300
Subject: [PATCH 1/3] [clang] Add tests for DRs about complete-class context
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/77444
>From 1cbf8eec15112cd6871fcfb69425c62f08c8f681 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 9 Jan 2024 14:17:21 +0300
Subject: [PATCH 1/2] [clang] Add tests for DRs about complete-class context
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/74061
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/74061
>From e6b9f54ce066e029b043e72281a7144338a84219 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Fri, 1 Dec 2023 13:35:23 +0300
Subject: [PATCH 1/4] [clang][NFC] Fill in historical data on when C++ DRs
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/74061
>From e6b9f54ce066e029b043e72281a7144338a84219 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Fri, 1 Dec 2023 13:35:23 +0300
Subject: [PATCH 1/3] [clang][NFC] Fill in historical data on when C++ DRs
Endilll wrote:
This PR is created to run the patch through CI, so no review requested.
https://github.com/llvm/llvm-project/pull/74061
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/74061
This patch continues the work started with
ea5b1ef016d020c37f903d6c7d4f623be975dab8. See that commit and its corresponding
PR for details.
>From e6b9f54ce066e029b043e72281a7144338a84219 Mon Sep 17 00:00:00
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/73879
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Endilll wrote:
> The human-readability of a big list of integers is not better than embedded
> base64 -- and actually, seems more of a pain to decode.
I agree that the entirety of the data is not too comprehensible, but I can
imagine users being interested in the first and last N bytes when
Endilll wrote:
Your reasoning works until we have a crash that relies on `#embed` and/or its
contents.
>From what I saw triaging old crashes, crash submitters are conscious if they
>work with proprietary code they can't share even a fragment of, and not so
>rarely reduce crash by themselves.
Endilll wrote:
I'd also like to highlight the use case of diagnostic for compiler crashes.
IIRC preprocessed source to attach to an issue is produced with
`-frewrite-includes`, so we might want to change its behavior for `#embed`.
This might be a good use case for `#embed_base64`.
Endilll wrote:
@AaronBallman Can you describe your current plan how driver options are going
to behave in the light of `#embed`?
https://github.com/llvm/llvm-project/pull/68620
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
Endilll wrote:
There has been multiple discussion in different places about behavior of `-E`,
`-M`, and friends (the most notable starts
[here](https://discord.com/channels/636084430946959380/636732781086638081/1175241241710055424)),
so I thought it would be a good idea to raise awareness
Endilll wrote:
@DavidSpickett There is `SBValue:SetFormat()`, which takes `lldb::Format`. We
can invent a new format, e.g. `eFormatEnumWithValue`. Not every enum flows
through my formatter, as I'm actively improving emitted debug info so that LLDB
does the right thing by default
Endilll wrote:
> For this use case I'm setting options in lldb_private::DumpValueObjectOptions
> down in C++ but I'm not sure if those directly map to what a formatter would
> have access to.
@DavidSpickett What exactly do you set or unset there to get the output you're
showing? This
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/71160
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/70349
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/70349
>From 7329f68092d5f8f5a5978e5a6cbad6ada87d4fe8 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Thu, 26 Oct 2023 16:09:25 +0300
Subject: [PATCH 1/7] [clang][NFC] Annotate `Type` bit-fields with
@@ -49,7 +49,7 @@ struct ExprDependenceScope {
using ExprDependence = ExprDependenceScope::ExprDependence;
struct TypeDependenceScope {
- enum TypeDependence : uint8_t {
+ enum TypeDependence : unsigned {
Endilll wrote:
I reverted changes to underlying
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/70349
>From 7329f68092d5f8f5a5978e5a6cbad6ada87d4fe8 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Thu, 26 Oct 2023 16:09:25 +0300
Subject: [PATCH 1/6] [clang][NFC] Annotate `Type` bit-fields with
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/70955
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/70955
During the recent refactoring (b120fe8d3288c4dca1b5427ca34839ce8833f71c) this
enum was moved out of `RecordDecl`. During post-commit review it was found out
that its association with `RecordDecl` should be
Author: Vlad Serebrennikov
Date: 2023-11-01T16:44:34+03:00
New Revision: 65761200ce4e1f366e8418652efdafd2f744291b
URL:
https://github.com/llvm/llvm-project/commit/65761200ce4e1f366e8418652efdafd2f744291b
DIFF:
Author: Vlad Serebrennikov
Date: 2023-11-01T13:40:11+03:00
New Revision: aaba3761db84032541712899964714f3184e8b3d
URL:
https://github.com/llvm/llvm-project/commit/aaba3761db84032541712899964714f3184e8b3d
DIFF:
Author: Vlad Serebrennikov
Date: 2023-11-01T11:49:59+03:00
New Revision: b120fe8d3288c4dca1b5427ca34839ce8833f71c
URL:
https://github.com/llvm/llvm-project/commit/b120fe8d3288c4dca1b5427ca34839ce8833f71c
DIFF:
Author: Vlad Serebrennikov
Date: 2023-10-31T18:21:36+03:00
New Revision: f5f4c5b313fc809b9b1b9d600d0ec3cec0d12941
URL:
https://github.com/llvm/llvm-project/commit/f5f4c5b313fc809b9b1b9d600d0ec3cec0d12941
DIFF:
Endilll wrote:
@clayborg Thank you for extensive feedback! Can you clarify where do you want
me to put the changes?
---
You expected the following:
> v.SetFormat(lldb.eFormatDecimal)
v.GetValue()
`1(1)`
But my patch doesn't seem to alter the behavior of `eFormatDecimal`. The code
and LLDB
@@ -23,9 +23,18 @@ def check_enum(self, suffix):
substrs=["Case1", "Case2", "Case3"],
)
# Test each case in the enum.
-self.expect_expr("var1_" + suffix, result_type=enum_name,
result_value="Case1")
-self.expect_expr("var2_" +
Endilll wrote:
> What happens with values that don't have a name, do we already have a
> fallback for that?
I think we do:
https://github.com/llvm/llvm-project/blob/2ad9fde41839879d8805d430c2e0857466d9c5d6/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp#L8563-L8571
Later there is a
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69815
>From 886c627b8675886cfa09745c2441e3ab4aaadaea Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sat, 21 Oct 2023 09:18:24 +0300
Subject: [PATCH 1/3] [lldb] Add number to enumerator dump
---
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69815
>From 886c627b8675886cfa09745c2441e3ab4aaadaea Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sat, 21 Oct 2023 09:18:24 +0300
Subject: [PATCH 1/2] [lldb] Add number to enumerator dump
---
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/69815
This patch adds the value to enumerator dump, e.g. `Enumerator` now dumped as
`Enumerator(0)`. There are not-so-uncommon cases when value of enumerator is no
less important than its name. One example can be
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/66879
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Endilll wrote:
Superseded by #68705
https://github.com/llvm/llvm-project/pull/66879
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/68705
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -720,6 +720,14 @@ SBType supports the eq/ne operator. For example,::
"
) lldb::SBType::GetTypeFlags;
+%feature("docstring",
+"Searches for a directly nested type that has provided name.
Endilll wrote:
Done
@@ -586,6 +586,15 @@ lldb::TemplateArgumentKind
SBType::GetTemplateArgumentKind(uint32_t idx) {
return eTemplateArgumentKindNull;
}
+SBType SBType::FindDirectNestedType(const char *name) {
+ LLDB_INSTRUMENT_VA(this, name);
+
+ if (!IsValid())
+return SBType();
+
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/68705
>From ca4d1bbdeb4ea541199e3db3518b35eb2d5a8cad Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 10 Oct 2023 15:07:56 +0300
Subject: [PATCH 01/15] [lldb] Add SBType::FindNestedType() function
---
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/68705
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -586,6 +586,15 @@ lldb::TemplateArgumentKind
SBType::GetTemplateArgumentKind(uint32_t idx) {
return eTemplateArgumentKindNull;
}
+SBType SBType::FindNestedType(const char *name) {
+ LLDB_INSTRUMENT_VA(this);
+
+ if (!IsValid())
+return SBType();
+ auto ret =
@@ -313,6 +313,8 @@ class TypeImpl {
bool GetDescription(lldb_private::Stream ,
lldb::DescriptionLevel description_level);
+ CompilerType FindNestedType(ConstString name);
Endilll wrote:
I followed @Michael137 suggestion that
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/68705
>From ca4d1bbdeb4ea541199e3db3518b35eb2d5a8cad Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 10 Oct 2023 15:07:56 +0300
Subject: [PATCH 01/14] [lldb] Add SBType::FindNestedType() function
---
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/68705
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -8,6 +8,9 @@ class Task {
TASK_TYPE_1,
TASK_TYPE_2
} type;
+enum E : unsigned char {} e;
+union U {
+} u;
Endilll wrote:
Done!
https://github.com/llvm/llvm-project/pull/68705
___
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/68705
>From ca4d1bbdeb4ea541199e3db3518b35eb2d5a8cad Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 10 Oct 2023 15:07:56 +0300
Subject: [PATCH 01/13] [lldb] Add SBType::FindNestedType() function
---
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/68705
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -119,6 +119,38 @@ def test(self):
self.assertEqual(task_type, task_head_pointee_type)
+# Check whether we can find a directly nested type by name
+name_type = task_type.FindDirectNestedType("name")
+self.assertTrue(name_type)
+
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/68705
>From ca4d1bbdeb4ea541199e3db3518b35eb2d5a8cad Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 10 Oct 2023 15:07:56 +0300
Subject: [PATCH 01/12] [lldb] Add SBType::FindNestedType() function
---
@@ -313,6 +313,8 @@ class TypeImpl {
bool GetDescription(lldb_private::Stream ,
lldb::DescriptionLevel description_level);
+ CompilerType FindNestedType(ConstString name);
Endilll wrote:
@jimingham @Michael137 Any opinions?
@@ -186,6 +186,11 @@ std::optional
TypeSystem::ReportStatistics() {
return std::nullopt;
}
+CompilerDeclContext
Endilll wrote:
Both items are done!
https://github.com/llvm/llvm-project/pull/68705
___
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/68705
>From ca4d1bbdeb4ea541199e3db3518b35eb2d5a8cad Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 10 Oct 2023 15:07:56 +0300
Subject: [PATCH 01/11] [lldb] Add SBType::FindNestedType() function
---
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/68705
>From ca4d1bbdeb4ea541199e3db3518b35eb2d5a8cad Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 10 Oct 2023 15:07:56 +0300
Subject: [PATCH 1/8] [lldb] Add SBType::FindNestedType() function
---
@@ -119,6 +119,15 @@ def test(self):
self.assertEqual(task_type, task_head_pointee_type)
+# Check whether we can find a nested type by name
+name_type = task_type.FindNestedType("name")
+self.assertTrue(name_type)
+
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/68705
>From ca4d1bbdeb4ea541199e3db3518b35eb2d5a8cad Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 10 Oct 2023 15:07:56 +0300
Subject: [PATCH 1/7] [lldb] Add SBType::FindNestedType() function
---
@@ -1082,6 +1082,19 @@ bool TypeImpl::GetDescription(lldb_private::Stream ,
return true;
}
+CompilerType TypeImpl::FindNestedType(ConstString name) {
Endilll wrote:
Done!
https://github.com/llvm/llvm-project/pull/68705
@@ -119,6 +119,11 @@ def test(self):
self.assertEqual(task_type, task_head_pointee_type)
+# Check whether we can find a nested type by name
+name_type = task_type.FindNestedType("name")
Endilll wrote:
Done!
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/68705
>From ca4d1bbdeb4ea541199e3db3518b35eb2d5a8cad Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Tue, 10 Oct 2023 15:07:56 +0300
Subject: [PATCH 1/6] [lldb] Add SBType::FindNestedType() function
---
@@ -119,6 +119,11 @@ def test(self):
self.assertEqual(task_type, task_head_pointee_type)
+# Check whether we can find a nested type by name
+name_type = task_type.FindNestedType("name")
Endilll wrote:
I can, but I'm not sure it would
1 - 100 of 123 matches
Mail list logo
