@@ -106,10 +106,13 @@ ScriptInterpreter::GetOpaqueTypeFromSBEvent(const
lldb::SBEvent &event) const {
return event.m_opaque_ptr;
}
-Stream *ScriptInterpreter::GetOpaqueTypeFromSBStream(
+lldb::StreamSP ScriptInterpreter::GetOpaqueTypeFromSBStream(
const lldb::SBStream
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 over
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 -DLLVM_ENABLE_PROJEC
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
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 flag
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 flag
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
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
___
lldb-commit
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&to=4feae05c6abda364a9295aecfa600d7d4e7dfeb6&stat=instructions:u
> While that's nice, it does suggest th
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
Author: Vlad Serebrennikov
Date: 2024-06-01T12:48:12+03:00
New Revision: cd676e5b27cb985697deac052c797057f5a33c06
URL:
https://github.com/llvm/llvm-project/commit/cd676e5b27cb985697deac052c797057f5a33c06
DIFF:
https://github.com/llvm/llvm-project/commit/cd676e5b27cb985697deac052c797057f5a33c06.
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
_
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 p
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:
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
lldb-commits@lists.llvm.o
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:
FYI there was a Linux pre-commit CI build recently that timed out on
`functionalities/single-thread-step/TestSingleThreadStepTimeout.py`:
https://buildkite.com/llvm-project/github-pull-requests/builds/91810
Relevant part of the log:
https://gist.github.com/Endilll/a15335f75f2aa4
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 amon
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
https://lists.ll
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`.
https://git
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:
> 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 th
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
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 2001
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://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commit
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
100
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
100
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/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
MI
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
MI
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
MI
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
MI
@@ -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
Author: Vlad Serebrennikov
Date: 2023-07-30T19:22:02+03:00
New Revision: fa2b038cadf17d08014e5fb75c47b5024860953e
URL:
https://github.com/llvm/llvm-project/commit/fa2b038cadf17d08014e5fb75c47b5024860953e
DIFF:
https://github.com/llvm/llvm-project/commit/fa2b038cadf17d08014e5fb75c47b5024860953e.
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/66879
Migrated from https://reviews.llvm.org/D156774
>From 72f83fb2944829c60bd6f12a079bfba95da4f6e7 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Thu, 14 Sep 2023 09:46:53 +0300
Subject: [PATCH 1/2] Implemen
@@ -462,3 +462,96 @@ TEST_F(DWARFASTParserClangTests,
TestDefaultTemplateParamParsing) {
}
}
}
+
+TEST_F(DWARFASTParserClangTests, EnsureNestedTypesOfTypeAreParsed) {
+ const char *yamldata = R"(
Endilll wrote:
I find this YAML way of describing debug
@@ -462,3 +462,96 @@ TEST_F(DWARFASTParserClangTests,
TestDefaultTemplateParamParsing) {
}
}
}
+
+TEST_F(DWARFASTParserClangTests, EnsureNestedTypesOfTypeAreParsed) {
+ const char *yamldata = R"(
+--- !ELF
+FileHeader:
+ Class: ELFCLASS64
+ Data:ELFDATA2LSB
+ T
@@ -462,3 +462,96 @@ TEST_F(DWARFASTParserClangTests,
TestDefaultTemplateParamParsing) {
}
}
}
+
+TEST_F(DWARFASTParserClangTests, EnsureNestedTypesOfTypeAreParsed) {
+ const char *yamldata = R"(
+--- !ELF
+FileHeader:
+ Class: ELFCLASS64
+ Data:ELFDATA2LSB
+ T
@@ -462,3 +462,96 @@ TEST_F(DWARFASTParserClangTests,
TestDefaultTemplateParamParsing) {
}
}
}
+
+TEST_F(DWARFASTParserClangTests, EnsureNestedTypesOfTypeAreParsed) {
+ const char *yamldata = R"(
+--- !ELF
+FileHeader:
+ Class: ELFCLASS64
+ Data:ELFDATA2LSB
+ T
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/66879
>From 72f83fb2944829c60bd6f12a079bfba95da4f6e7 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Thu, 14 Sep 2023 09:46:53 +0300
Subject: [PATCH 1/3] Implementation (migrated from Phabricator)
---
.../Sym
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 a
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 p
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 pus
Endilll wrote:
> For me the picture is limited to register printing. I'll be setting this new
> option on the register type when printing
> (https://github.com/DavidSpickett/llvm-project/commit/24dbefaa14030646ba0871298989558221af1ba0#diff-18135f619417bbaa1ab0c181ce55b2c55681323c06e90fa1a3e1609
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
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
@@ -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 tem
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 '
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:
> 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 maintain
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
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 class
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
lldb-
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 class
@@ -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 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
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 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
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://lists.llvm.org/cgi-bin/mailman/listinf
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
https://l
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
https://lists.l
Author: Vlad Serebrennikov
Date: 2024-02-16T22:47:09+03:00
New Revision: 4214f25dccba36472c9666f1395eef894dca1bba
URL:
https://github.com/llvm/llvm-project/commit/4214f25dccba36472c9666f1395eef894dca1bba
DIFF:
https://github.com/llvm/llvm-project/commit/4214f25dccba36472c9666f1395eef894dca1bba.
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/68705
This patch adds a `SBType::FindNestedType(name)` function which performs a
non-recursive search in given class for a type with specified name. The intent
is to perform a fast search in debug info, so that it can
Endilll wrote:
Intended usage is going to look like the following for `PointerIntPair`:
```python
class PointerIntPairProvider:
def update(self):
pointer_info = self.valobj.type.template_args[4] # PointerIntPairInfo
masks = pointer_info.FindNestedType("MaskAndShiftConstants")
Endilll wrote:
It should be noted that after calling `FindNestedType` and successfully finding
`MaskAndShiftConstants` in the example above, the following routine in my fork
reports that `PointerIntPairInfo` has 2 enums instead of 1:
```cpp
uint32_t TypeSystemClang::GetNumMemberEnums(lldb::opaq
Endilll wrote:
> Is FindNestedType guaranteed to have a single return?
Yes, because search is not recursive, i.e. doesn't search inside nested types.
I'm intentionally specifying `FindNestedType` this way, because I'd like it to
not do too much to remain fast by design, and I'm yet to see a use
Endilll wrote:
`depth` parameter makes sense to me.
I wonder if it should have a default value 0 meaning infinite depth.
Now I wonder how my current implementation behaves with respect to depth, which
is actually embarrassing. And how to implement `depth` parameter.
https://github.com/llvm/ll
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/3] [lldb] Add SBType::FindNestedType() function
---
lldb/
@@ -1082,6 +1082,19 @@ bool TypeImpl::GetDescription(lldb_private::Stream &strm,
return true;
}
+CompilerType TypeImpl::FindNestedType(ConstString name) {
+ auto type_system = GetTypeSystem(false);
Endilll wrote:
Done!
https://github.com/llvm/llvm-project
@@ -1082,6 +1082,19 @@ bool TypeImpl::GetDescription(lldb_private::Stream &strm,
return true;
}
+CompilerType TypeImpl::FindNestedType(ConstString name) {
+ auto type_system = GetTypeSystem(false);
+ auto *symbol_file = type_system->GetSymbolFile();
+ auto decl_context =
@@ -586,6 +586,15 @@ lldb::TemplateArgumentKind
SBType::GetTemplateArgumentKind(uint32_t idx) {
return eTemplateArgumentKindNull;
}
+SBType SBType::FindNestedType(const char *name) {
+ LLDB_INSTRUMENT_VA(this);
Endilll wrote:
I didn't knew this. Thank you
@@ -313,6 +313,8 @@ class TypeImpl {
bool GetDescription(lldb_private::Stream &strm,
lldb::DescriptionLevel description_level);
+ CompilerType FindNestedType(ConstString name);
Endilll wrote:
> Do we want to make a ConstString for eve
Endilll wrote:
@jimingham
https://github.com/llvm/llvm-project/blob/d5444ab26743115e42e4abb3782bbefb0e8912d0/lldb/source/Symbol/CompilerDeclContext.cpp#L49-L61
and
https://github.com/llvm/llvm-project/blob/d5444ab26743115e42e4abb3782bbefb0e8912d0/lldb/source/Plugins/TypeSystem/Clang/TypeSystemCla
Endilll wrote:
> find A::B::C which is a match, note max_matches == 1 and return
Looking at `DeclContextIsContainedInLookup`, `A::B::C` is not a match, because
it's `DeclContext` is not `DeclContext` of `A`. This is of course is not
future-proof against changes to `DeclContextIsContainedInLook
Endilll wrote:
It's not clear to me whether `TypeSystem::DeclContextIsContainedInLookup`
provides such a guarantee. Implementation suggests that it's only interested in
direct `DeclContext`, maybe ignoring transparent decl contexts like inline
namespace it already handles. I hope reviewers can
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/4] [lldb] Add SBType::FindNestedType() function
---
lldb/
@@ -1082,6 +1082,19 @@ bool TypeImpl::GetDescription(lldb_private::Stream &strm,
return true;
}
+CompilerType TypeImpl::FindNestedType(ConstString name) {
Endilll wrote:
Makes sense.
IIRC it's possible to have multiple anonymous unions, so it's not going to
@@ -186,6 +186,11 @@ std::optional
TypeSystem::ReportStatistics() {
return std::nullopt;
}
+CompilerDeclContext
Endilll wrote:
> Could add a brief oxygen docstring saying: "Returns the direct parent context
> of specified type".
I'd be happy to do that a
@@ -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
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
---
lldb/
@@ -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/llvm/ll
@@ -1082,6 +1082,19 @@ bool TypeImpl::GetDescription(lldb_private::Stream &strm,
return true;
}
+CompilerType TypeImpl::FindNestedType(ConstString name) {
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 1/7] [lldb] Add SBType::FindNestedType() function
---
lldb/
@@ -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)
+self.DebugSBType(name
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
---
lldb/
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
---
lld
@@ -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
___
lldb-commit
@@ -313,6 +313,8 @@ class TypeImpl {
bool GetDescription(lldb_private::Stream &strm,
lldb::DescriptionLevel description_level);
+ CompilerType FindNestedType(ConstString name);
Endilll wrote:
@jimingham @Michael137 Any opinions?
http
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
---
lld
@@ -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)
+self.D
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
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
---
lld
@@ -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
___
l
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
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
---
lld
@@ -313,6 +313,8 @@ class TypeImpl {
bool GetDescription(lldb_private::Stream &strm,
lldb::DescriptionLevel description_level);
+ CompilerType FindNestedType(ConstString name);
Endilll wrote:
I followed @Michael137 suggestion that `Ty
@@ -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 = SBTyp
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
1 - 100 of 126 matches
Mail list logo
