https://github.com/felipepiovezan created
https://github.com/llvm/llvm-project/pull/100624
This is useful for language runtimes that compute register values by inspecting
the state of the currently running process. Currently, there are no mechanisms
enabling these runtimes to set register valu
@@ -153,6 +155,9 @@ void UnwindPlan::Row::RegisterLocation::Dump(Stream &s,
if (m_type == atDWARFExpression)
s.PutChar(']');
} break;
+ case isConstant:
+s.Printf("=%x", m_location.offset);
felipepiovezan wrote:
Ohh oops, you're totally right!
https://github.com/felipepiovezan updated
https://github.com/llvm/llvm-project/pull/100624
>From 223075d6f036537a7edec10b370f6d922135cb79 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Tue, 23 Jul 2024 13:30:40 -0700
Subject: [PATCH 1/2] [lldb] Add constant value mode for Regis
https://github.com/felipepiovezan closed
https://github.com/llvm/llvm-project/pull/100624
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -351,136 +352,32 @@ static void
SetupDefaultClangDiagnostics(CompilerInstance &compiler) {
}
}
-//===--===//
-// Implementation of ClangExpressionParser
-//===
https://github.com/felipepiovezan approved this pull request.
https://github.com/llvm/llvm-project/pull/102539
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
felipepiovezan wrote:
LGTM! Good catch!
https://github.com/llvm/llvm-project/pull/102539
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/felipepiovezan approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/92618
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/felipepiovezan edited
https://github.com/llvm/llvm-project/pull/92745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -9,7 +9,7 @@
#include "Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h"
#include "Plugins/SymbolFile/DWARF/DWARFDebugInfo.h"
#include "Plugins/SymbolFile/DWARF/DWARFDeclContext.h"
-#include "Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h"
+#include "Plugins/SymbolFile/DWARF/L
https://github.com/felipepiovezan approved this pull request.
Great catch and fix! Thanks for doing this
https://github.com/llvm/llvm-project/pull/92745
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
felipepiovezan wrote:
> I think #77696 is justification enough to add this check, but I don't think
> we should be implicating DW_IDX_parent_entries until we know how those came
> about.
This is pretty much my point, the workaround is fine, but I don't think the
source-code comment in this P
https://github.com/felipepiovezan approved this pull request.
LGTM! Thanks for catching this
https://github.com/llvm/llvm-project/pull/93006
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-
@@ -195,17 +195,17 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
if (!ref)
continue;
-DWARFUnit *cu = m_debug_info.GetUnit(*ref);
-if (!cu || !cu->Supports_DW_AT_APPLE_objc_complete_type()) {
- incomplete_types.push_back(*ref);
- continue;
-
https://github.com/felipepiovezan edited
https://github.com/llvm/llvm-project/pull/92894
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/felipepiovezan edited
https://github.com/llvm/llvm-project/pull/92894
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/felipepiovezan edited
https://github.com/llvm/llvm-project/pull/92894
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
felipepiovezan wrote:
>Since clang no longer emits entry for:
But what does the `debug_info` section look like? In particular, what is the
_parent_ of the class DIE?
If the parent of `InnerState` is not some kind of entry for `State` (either a
declaration or a definition), IMO Clang is genera
felipepiovezan wrote:
Ohhh ok, I just inspected the debug_names/debug_info sections; there is no
parent at all for the InnerState debug_names entry. In this case, the
debug_names section is valid. Unfortunate, as this may cause entire CUs/TUs to
be parsed (because of all the calls to Process
felipepiovezan wrote:
> Current BOLT behavior is to skip that DIE and reference it's parent:
This, on the other hand, is concerning. It needs to reflect the debug_info
section, otherwise we can't use debug_names to answer queries like "find
A::B::C::D".
It would be better if the BOLT compiler
felipepiovezan wrote:
These types of changes touching a lot of projects at once can benefit from
multiple PRs, one per project, as it makes partial reverts a lot easier and
doesn't cause as much churn downstream (plus we can get more targeted comments
from individual project owners)
https://g
@@ -183,27 +181,22 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
llvm::function_ref callback) {
// Keep a list of incomplete types as fallback for when we don't find the
// complete type.
- DIEArray incomplete_types;
+ std::vector incomplete_types;
-
https://github.com/felipepiovezan approved this pull request.
I think this should probably be fine (perf-wise)!
https://github.com/llvm/llvm-project/pull/93296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
felipepiovezan wrote:
> > Discussed with Pavel, I applied this change to #92328 so we can ensure the
> > DIEs from the index is always definition DIEs and avoid duplicate/expensive
> > checks later.
>
> To elaborate, I suggested Zequan does this, because I think there's consensus
> that this
felipepiovezan wrote:
thanks for well-written summary @dwblaikie !
https://github.com/llvm/llvm-project/pull/91808
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/felipepiovezan approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/92894
___
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) {
felipepiovezan wrote:
Yeah, we definitely need to clean all of these up.
There might be one inside ll
felipepiovezan wrote:
> @felipepiovezan I have another question. For the same example. I see:
>
> ```
> Name 4 {
> Hash: 0x2F94396D
> String: 0x0049 "_Z9get_statev"
> Entry @ 0x112 {
> Abbrev: 0x2
> Tag: DW_TAG_subprogram
> DW_IDX_die_offset: 0x0
felipepiovezan wrote:
>Should we allow such entries in the index? And does this warrant rephrasing in
>the DWARF spec?
It's fine to have those as _nameless_ entries (which we don't emit today), but
the entries that are reaching "process entry" are not nameless by definition.
That if statement
https://github.com/felipepiovezan approved this pull request.
https://github.com/llvm/llvm-project/pull/94400
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
felipepiovezan wrote:
@oontvoo I think this broke the bots again:
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/5341/console
https://github.com/llvm/llvm-project/pull/87550
___
lldb-commits mailing list
lldb-commits@lists.llvm.or
felipepiovezan wrote:
Would you mind reverting it until you have a chance to look at the failures?
https://github.com/llvm/llvm-project/pull/87550
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
felipepiovezan wrote:
Oops, I commented on the old PR instead of the new one, so let me copy paste it
here:
@oontvoo I think this broke the bots again:
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/5341/console
Would you mind reverting it until you have a chance to look a
felipepiovezan wrote:
@oontvoo I'm going to revert this for now as the incremental bots are our first
line of defense against failures
https://github.com/llvm/llvm-project/pull/94625
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://li
Author: Felipe de Azevedo Piovezan
Date: 2024-06-07T10:14:58-07:00
New Revision: adcf33f8fbcc0f068bd4b8254994b16dda525009
URL:
https://github.com/llvm/llvm-project/commit/adcf33f8fbcc0f068bd4b8254994b16dda525009
DIFF:
https://github.com/llvm/llvm-project/commit/adcf33f8fbcc0f068bd4b8254994b16dd
https://github.com/felipepiovezan approved this pull request.
https://github.com/llvm/llvm-project/pull/95015
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -975,6 +975,219 @@ ConvertDWARFCallingConventionToClang(const
ParsedDWARFTypeAttributes &attrs) {
return clang::CC_C;
}
+bool DWARFASTParserClang::ParseObjCMethod(
+const ObjCLanguage::MethodName &objc_method, const DWARFDIE &die,
+CompilerType clang_type, const
@@ -975,6 +975,219 @@ ConvertDWARFCallingConventionToClang(const
ParsedDWARFTypeAttributes &attrs) {
return clang::CC_C;
}
+bool DWARFASTParserClang::ParseObjCMethod(
+const ObjCLanguage::MethodName &objc_method, const DWARFDIE &die,
+CompilerType clang_type, const
https://github.com/felipepiovezan approved this pull request.
It's say something that, even after this refactor, the methods are still pretty
big. But this is still a win
https://github.com/llvm/llvm-project/pull/95078
___
lldb-commits mailing list
ll
@@ -975,6 +975,219 @@ ConvertDWARFCallingConventionToClang(const
ParsedDWARFTypeAttributes &attrs) {
return clang::CC_C;
}
+bool DWARFASTParserClang::ParseObjCMethod(
+const ObjCLanguage::MethodName &objc_method, const DWARFDIE &die,
+CompilerType clang_type, const
@@ -975,6 +975,219 @@ ConvertDWARFCallingConventionToClang(const
ParsedDWARFTypeAttributes &attrs) {
return clang::CC_C;
}
+bool DWARFASTParserClang::ParseObjCMethod(
+const ObjCLanguage::MethodName &objc_method, const DWARFDIE &die,
+CompilerType clang_type, const
https://github.com/felipepiovezan edited
https://github.com/llvm/llvm-project/pull/95078
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -975,6 +975,219 @@ ConvertDWARFCallingConventionToClang(const
ParsedDWARFTypeAttributes &attrs) {
return clang::CC_C;
}
+bool DWARFASTParserClang::ParseObjCMethod(
+const ObjCLanguage::MethodName &objc_method, const DWARFDIE &die,
+CompilerType clang_type, const
https://github.com/felipepiovezan edited
https://github.com/llvm/llvm-project/pull/95078
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Felipe de Azevedo Piovezan
Date: 2024-06-11T09:28:10-07:00
New Revision: 2e007b89c65eeb33baf1b40103284d8937700cf0
URL:
https://github.com/llvm/llvm-project/commit/2e007b89c65eeb33baf1b40103284d8937700cf0
DIFF:
https://github.com/llvm/llvm-project/commit/2e007b89c65eeb33baf1b40103284d893
felipepiovezan wrote:
hi @dzhidzhoev, I think this commit is causing the arm lldb incremental bots to
fail.
Could you have a look or revert if you think the fix is not obvious? This is
our most important bot, so it would be nice to get it green again
https://green.lab.llvm.org/job/llvm.org/view
felipepiovezan wrote:
@dzhidzhoev I think @labath 's suggestion might fix this (LD_EXTRAS)
https://github.com/llvm/llvm-project/pull/93808
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-co
Author: Felipe de Azevedo Piovezan
Date: 2024-06-12T09:32:54-07:00
New Revision: c5790206f719c8fac168ae488420f31800d55cf0
URL:
https://github.com/llvm/llvm-project/commit/c5790206f719c8fac168ae488420f31800d55cf0
DIFF:
https://github.com/llvm/llvm-project/commit/c5790206f719c8fac168ae488420f3180
felipepiovezan wrote:
Pushed a fix
https://github.com/llvm/llvm-project/pull/93808
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
felipepiovezan wrote:
> LGTM, may be we could also support this for the command line
Just keep in mind that those are very different queries w.r.t. speed: one goes
through a fast path in the accelerator table, the other one doesn't.
https://github.com/llvm/llvm-project/pull/95350
_
https://github.com/felipepiovezan created
https://github.com/llvm/llvm-project/pull/95449
This test is explicitly checking for dwarf 4 behavior on Apple platforms, so we
should explicitly use the dwarf4 flag.
Related to https://github.com/llvm/llvm-project/pull/95164
>From d4915d55cfbef6f9d41
https://github.com/felipepiovezan approved this pull request.
https://github.com/llvm/llvm-project/pull/95582
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/felipepiovezan closed
https://github.com/llvm/llvm-project/pull/95449
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
felipepiovezan wrote:
Isn't this going to degrade the performance of _all_ negative queries?
I don't remember off the top of my head what is "m_fallback" when we have an
accelerator table, but this worries me.
https://github.com/llvm/llvm-project/pull/102123
felipepiovezan wrote:
> The fallback index will only index those units that aren't covered by the
> debug_names index, so if debug_names covers everything, the fallback is a noop
Got it, this is what I was hoping that would happen! Thanks for explaining it.
(future ideas) This makes me wonder
felipepiovezan wrote:
> The current setup makes sense to me, but I guess that's expected as I'm the
> one who created it. I can also imagine something like what you propose, but
> it doesn't seem like a clear win to me. These objects are owned by
> SymbolFileDWARF, and we probably don't want t
https://github.com/felipepiovezan created
https://github.com/llvm/llvm-project/pull/105873
The existing algorithm was performing the following comparisons for an
`aaa,bbb,ccc,ddd`:
aaa\0bbb,ccc,ddd == "stack"
aaa\0bbb\0ccc,ddd == "stack"
aaa\0bbb\0ccc\0ddd == "stack"
Which wouldn't work. This
felipepiovezan wrote:
Since this is mostly uncontroversial, I am going to go ahead and merge it now.
Happy to address feedback in post!
https://github.com/llvm/llvm-project/pull/105873
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https:/
https://github.com/felipepiovezan updated
https://github.com/llvm/llvm-project/pull/105873
>From fbe4fdfb0e804c281ed5c52382ef4bb16ec9fce5 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Fri, 23 Aug 2024 11:43:16 -0700
Subject: [PATCH] [GDBRemote] Fix processing of comma-separate
felipepiovezan wrote:
Fixed clang format issue
https://github.com/llvm/llvm-project/pull/105873
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/felipepiovezan closed
https://github.com/llvm/llvm-project/pull/105873
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/felipepiovezan created
https://github.com/llvm/llvm-project/pull/105883
This should cause the memory region info "is stack" field to be set to "no".
>From 0730cd7f48dd4b80fba0275fed9beadcf6193987 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Fri, 23 Aug 202
https://github.com/felipepiovezan updated
https://github.com/llvm/llvm-project/pull/105883
>From e91140e2c059df5f65ad907e9c93329c75e36dc4 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Fri, 23 Aug 2024 13:10:00 -0700
Subject: [PATCH 1/2] [GDBRemote] Handle 'heap' memory region
https://github.com/felipepiovezan closed
https://github.com/llvm/llvm-project/pull/105883
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
felipepiovezan wrote:
I'm not if this is your intention, but the way LLVM has configured their
github, your two nicely separated commits will be squashed :(
https://github.com/llvm/llvm-project/pull/107170
___
lldb-commits mailing list
lldb-commits@l
felipepiovezan wrote:
Ah I've just noticed the other PR
https://github.com/llvm/llvm-project/pull/107170
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
felipepiovezan wrote:
> > Ah I've just noticed the other PR
>
> Do we actually have abetter solution for stacked commits than what I'm doing
> here?
short answer is "maybe":
https://llvm.org/docs/GitHub.html#using-graphite-for-stacked-pull-requests
https://github.com/llvm/llvm-project/pull/1
felipepiovezan wrote:
> @felipepiovezan Are you OK if we push this as-is, or would you like smarter
> logic for detecting libc++ on the system?
I'm fine with this; in hindsight, I think the original workaround was not good
enough.
The longer term fix would be set both "use system std library"
https://github.com/felipepiovezan approved this pull request.
https://github.com/llvm/llvm-project/pull/106885
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/felipepiovezan approved this pull request.
LGTM!
Not sure why the formatter is complaining about a single line deletion
https://github.com/llvm/llvm-project/pull/108003
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https:
https://github.com/felipepiovezan created
https://github.com/llvm/llvm-project/pull/108281
If multiple breakpoints are hit at the same time, multiple stop reasons are
reported, one per breakpoint.
Currently, `get_threads_stopped_at_breakpoint_id` only checks the first such
reason.
>From 09a4
felipepiovezan wrote:
I only hit this bug in a downstream test. It seems we don't directly test
lldbutil, but none of the tests regress with this change, so we should be
confident it is ok.
https://github.com/llvm/llvm-project/pull/108281
___
lldb-co
https://github.com/felipepiovezan closed
https://github.com/llvm/llvm-project/pull/108281
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -436,8 +482,8 @@ class CompilerType {
ExecutionContextScope *exe_scope);
/// Dump to stdout.
- void DumpTypeDescription(lldb::DescriptionLevel level =
- lldb::eDescriptionLevelFull) const;
felipepiovezan wro
@@ -249,7 +250,7 @@ bool CompilerType::IsPossibleDynamicType(CompilerType
*dynamic_pointee_type,
if (IsValid())
if (auto type_system_sp = GetTypeSystem())
return type_system_sp->IsPossibleDynamicType(m_type,
dynamic_pointee_type,
-
@@ -302,6 +303,256 @@ bool CompilerType::IsBeingDefined() const {
return false;
}
+bool CompilerType::IsSmartPtrType() const {
+ // These regular expressions cover shared, unique and weak pointers both from
+ // stdlibc++ and libc+++.
+
+ static llvm::Regex k_libcxx_std_u
@@ -302,6 +303,256 @@ bool CompilerType::IsBeingDefined() const {
return false;
}
+bool CompilerType::IsSmartPtrType() const {
+ // These regular expressions cover shared, unique and weak pointers both from
+ // stdlibc++ and libc+++.
+
+ static llvm::Regex k_libcxx_std_u
@@ -302,6 +303,256 @@ bool CompilerType::IsBeingDefined() const {
return false;
}
+bool CompilerType::IsSmartPtrType() const {
+ // These regular expressions cover shared, unique and weak pointers both from
+ // stdlibc++ and libc+++.
+
+ static llvm::Regex k_libcxx_std_u
@@ -54,7 +54,7 @@ bool CompilerType::IsArrayType(CompilerType
*element_type_ptr, uint64_t *size,
if (IsValid())
if (auto type_system_sp = GetTypeSystem())
return type_system_sp->IsArrayType(m_type, element_type_ptr, size,
- is_i
@@ -302,6 +303,256 @@ bool CompilerType::IsBeingDefined() const {
return false;
}
+bool CompilerType::IsSmartPtrType() const {
+ // These regular expressions cover shared, unique and weak pointers both from
+ // stdlibc++ and libc+++.
+
+ static llvm::Regex k_libcxx_std_u
@@ -302,6 +303,256 @@ bool CompilerType::IsBeingDefined() const {
return false;
}
+bool CompilerType::IsSmartPtrType() const {
+ // These regular expressions cover shared, unique and weak pointers both from
+ // stdlibc++ and libc+++.
+
+ static llvm::Regex k_libcxx_std_u
@@ -302,6 +303,256 @@ bool CompilerType::IsBeingDefined() const {
return false;
}
+bool CompilerType::IsSmartPtrType() const {
+ // These regular expressions cover shared, unique and weak pointers both from
+ // stdlibc++ and libc+++.
+
+ static llvm::Regex k_libcxx_std_u
@@ -157,7 +157,8 @@ bool CompilerType::IsBlockPointerType(
CompilerType *function_pointer_type_ptr) const {
if (IsValid())
if (auto type_system_sp = GetTypeSystem())
- return type_system_sp->IsBlockPointerType(m_type,
function_pointer_type_ptr);
+ return ty
https://github.com/felipepiovezan closed
https://github.com/llvm/llvm-project/pull/73707
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -436,8 +482,8 @@ class CompilerType {
ExecutionContextScope *exe_scope);
/// Dump to stdout.
- void DumpTypeDescription(lldb::DescriptionLevel level =
- lldb::eDescriptionLevelFull) const;
felipepiovezan wro
@@ -436,8 +482,8 @@ class CompilerType {
ExecutionContextScope *exe_scope);
/// Dump to stdout.
- void DumpTypeDescription(lldb::DescriptionLevel level =
- lldb::eDescriptionLevelFull) const;
felipepiovezan wro
@@ -807,6 +808,23 @@ void
CommandCompletions::TypeCategoryNames(CommandInterpreter &interpreter,
});
}
+void CommandCompletions::ThreadIDs(CommandInterpreter &interpreter,
+ CompletionRequest &request,
+
@@ -436,8 +482,8 @@ class CompilerType {
ExecutionContextScope *exe_scope);
/// Dump to stdout.
- void DumpTypeDescription(lldb::DescriptionLevel level =
- lldb::eDescriptionLevelFull) const;
felipepiovezan wro
https://github.com/felipepiovezan edited
https://github.com/llvm/llvm-project/pull/73596
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/felipepiovezan created
https://github.com/llvm/llvm-project/pull/74119
This PR cleans up OptionArgParser in a couple of ways:
1. We remove unnecessary std::string temporaries
2. Through else-after-return elimination, we prove the existence of unreachable
code
>From 6f502ee6
https://github.com/felipepiovezan edited
https://github.com/llvm/llvm-project/pull/74119
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/felipepiovezan updated
https://github.com/llvm/llvm-project/pull/74119
>From d4143eea927eed4f4f0efaa9e1657de5f452a257 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Fri, 1 Dec 2023 09:07:11 -0800
Subject: [PATCH 1/3] [lldb][NFC] Remove unnecessary std::string
felipepiovezan wrote:
> Github makes this look extremely complicated but in my editor this all looks
> pretty obvious. LGTM.
Yeah, that's part of the reason I tried to break the changes into smaller bits,
but it still doesn't look as obvious as I wish it did
https://github.com/llvm/llvm-proje
Author: Felipe de Azevedo Piovezan
Date: 2023-12-04T10:23:04-08:00
New Revision: 7a86cc6c4ca11e37d5985d4fc902658ab6ad0e22
URL:
https://github.com/llvm/llvm-project/commit/7a86cc6c4ca11e37d5985d4fc902658ab6ad0e22
DIFF:
https://github.com/llvm/llvm-project/commit/7a86cc6c4ca11e37d5985d4fc902658ab
Author: Felipe de Azevedo Piovezan
Date: 2023-12-04T10:23:05-08:00
New Revision: 3e98a285138a517fd918ec0ac8397dc56330d8e7
URL:
https://github.com/llvm/llvm-project/commit/3e98a285138a517fd918ec0ac8397dc56330d8e7
DIFF:
https://github.com/llvm/llvm-project/commit/3e98a285138a517fd918ec0ac8397dc56
Author: Felipe de Azevedo Piovezan
Date: 2023-12-04T10:23:05-08:00
New Revision: d24d7edaef9517edd9eb2ab26b02969e201bbcad
URL:
https://github.com/llvm/llvm-project/commit/d24d7edaef9517edd9eb2ab26b02969e201bbcad
DIFF:
https://github.com/llvm/llvm-project/commit/d24d7edaef9517edd9eb2ab26b02969e2
https://github.com/felipepiovezan closed
https://github.com/llvm/llvm-project/pull/74119
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
felipepiovezan wrote:
Pushed as
```
* d24d7edaef95 (2 minu..) fpiove.. [lldb][NFC] Delete unreachable code and dead
│
variable in OptionArgParser
│
* 3e98a285138a (2 minu..) fpiove.. [lld
felipepiovezan wrote:
It is wild that all of these have gone unnoticed for such a long time. I guess
it makes sense, as these are more of sanity checks that we never expect to fire?
https://github.com/llvm/llvm-project/pull/74414
___
lldb-commits mail
felipepiovezan wrote:
Should we change the documentation of these functions?
https://github.com/llvm/llvm-project/pull/74413
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
1 - 100 of 517 matches
Mail list logo
