https://github.com/jayfoad updated
https://github.com/llvm/llvm-project/pull/74863
>From e406c734609d3cd1ae436084c42c1c63d8af2795 Mon Sep 17 00:00:00 2001
From: Jay Foad
Date: Fri, 8 Dec 2023 14:08:09 +
Subject: [PATCH 1/2] [GlobalISel] Add G_PREFETCH
---
.../CodeGen/GlobalISel/MachineIRB
Author: Felipe de Azevedo Piovezan
Date: 2023-12-11T08:01:04-03:00
New Revision: 162248c22dcfa0674efd339f35717ea711b8e025
URL:
https://github.com/llvm/llvm-project/commit/162248c22dcfa0674efd339f35717ea711b8e025
DIFF:
https://github.com/llvm/llvm-project/commit/162248c22dcfa0674efd339f35717ea71
https://github.com/felipepiovezan closed
https://github.com/llvm/llvm-project/pull/74773
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jayfoad closed
https://github.com/llvm/llvm-project/pull/74863
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Michael137 wrote:
> > Sorry, it's been a while since I last reviewed this and I must admit I
> > forgot about this in the mean time. The only thing I'd like to check before
> > we can land this is to hear from @Michael137 who has been actively working
> > on FindTypes performance recently whet
@@ -45,6 +66,286 @@ struct CompilerContext {
bool contextMatches(llvm::ArrayRef context_chain,
llvm::ArrayRef pattern);
+FLAGS_ENUM(TypeQueryOptions){
+e_none = 0u,
+/// If set TypeQuery::m_context contains an exact context that must match
+///
https://github.com/felipepiovezan updated
https://github.com/llvm/llvm-project/pull/74788
>From 5a5309c1c81fadb0378f1fa821798471f00f9b29 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Thu, 7 Dec 2023 15:45:05 -0800
Subject: [PATCH] [lldb][NFC] Simplify DWARRFDeclContext::GetQua
https://github.com/felipepiovezan updated
https://github.com/llvm/llvm-project/pull/74788
>From 19452a77fbaa8376686ae9fcdb6c675621f515d8 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Thu, 7 Dec 2023 15:45:05 -0800
Subject: [PATCH] [lldb][NFC] Simplify DWARRFDeclContext::GetQua
@@ -437,26 +437,25 @@ lldb::SBType SBModule::FindFirstType(const char
*name_cstr) {
LLDB_INSTRUMENT_VA(this, name_cstr);
ModuleSP module_sp(GetSP());
- if (!name_cstr || !module_sp)
Michael137 wrote:
why did we get rid of the early return here?
https:/
@@ -437,26 +437,25 @@ lldb::SBType SBModule::FindFirstType(const char
*name_cstr) {
LLDB_INSTRUMENT_VA(this, name_cstr);
ModuleSP module_sp(GetSP());
- if (!name_cstr || !module_sp)
-return {};
- SymbolContext sc;
- const bool exact_match = false;
- ConstString na
https://github.com/Michael137 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/74788
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -45,6 +66,286 @@ struct CompilerContext {
bool contextMatches(llvm::ArrayRef context_chain,
llvm::ArrayRef pattern);
+FLAGS_ENUM(TypeQueryOptions){
+e_none = 0u,
+/// If set TypeQuery::m_context contains an exact context that must match
+///
@@ -502,11 +499,8 @@ lldb::SBTypeList SBModule::FindTypes(const char *type) {
retval.Append(SBType(compiler_type));
}
} else {
- for (size_t idx = 0; idx < type_list.GetSize(); idx++) {
-TypeSP type_sp(type_list.GetTypeAtIndex(idx));
-
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/74786
___
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: 2023-12-11T11:16:36-03:00
New Revision: 06d6af72fb6f87cebe90ab96fa56fb88f53d5f66
URL:
https://github.com/llvm/llvm-project/commit/06d6af72fb6f87cebe90ab96fa56fb88f53d5f66
DIFF:
https://github.com/llvm/llvm-project/commit/06d6af72fb6f87cebe90ab96fa56fb88f
https://github.com/felipepiovezan closed
https://github.com/llvm/llvm-project/pull/74788
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -146,6 +133,9 @@ class TypeSystem : public PluginInterface,
virtual CompilerDeclContext
GetCompilerDeclContextForType(const CompilerType &type);
+ virtual std::vector
+ DeclContextGetCompilerContext(void *opaque_decl_ctx);
Michael137 wrote:
could thi
@@ -122,6 +106,9 @@ class TypeSystem : public PluginInterface,
virtual CompilerType DeclGetFunctionArgumentType(void *opaque_decl,
size_t arg_idx);
+ virtual std::vector
+ DeclGetCompilerContext(void *opaque_decl);
---
@@ -1696,16 +1696,16 @@ static size_t LookupTypeInModule(Target *target,
CommandInterpreter &interpreter, Stream &strm,
Module *module, const char *name_cstr,
bool name_is_regex)
@@ -73,9 +73,22 @@ class DWARFDIE : public DWARFBaseDIE {
std::vector GetDeclContextDIEs() const;
/// Return this DIE's decl context as it is needed to look up types
- /// in Clang's -gmodules debug info format.
+ /// in Clang modules. This context will include any modul
@@ -12,33 +12,32 @@ class UniqueTypesTestCase4(TestBase):
def do_test(self, debug_flags):
"""Test that we display the correct template instantiation."""
self.build(dictionary=debug_flags)
+exe = self.getBuildArtifact("a.out")
+print(exe)
@@ -12,33 +12,32 @@ class UniqueTypesTestCase4(TestBase):
def do_test(self, debug_flags):
"""Test that we display the correct template instantiation."""
self.build(dictionary=debug_flags)
+exe = self.getBuildArtifact("a.out")
+print(exe)
@@ -12,33 +12,32 @@ class UniqueTypesTestCase4(TestBase):
def do_test(self, debug_flags):
"""Test that we display the correct template instantiation."""
self.build(dictionary=debug_flags)
+exe = self.getBuildArtifact("a.out")
+print(exe)
@@ -1859,17 +1851,11 @@ lldb::SBTypeList SBTarget::FindTypes(const char
*typename_cstr) {
if (typename_cstr && typename_cstr[0] && target_sp) {
ModuleList &images = target_sp->GetImages();
ConstString const_typename(typename_cstr);
-bool exact_match = false;
-
@@ -12,33 +12,32 @@ class UniqueTypesTestCase4(TestBase):
def do_test(self, debug_flags):
"""Test that we display the correct template instantiation."""
self.build(dictionary=debug_flags)
+exe = self.getBuildArtifact("a.out")
+print(exe)
@@ -1446,23 +1446,23 @@ void SymbolFilePDB::AddSymbols(lldb_private::Symtab
&symtab) {
symtab.Finalize();
}
-void SymbolFilePDB::FindTypes(
-lldb_private::ConstString name, const CompilerDeclContext &parent_decl_ctx,
-uint32_t max_matches,
-llvm::DenseSet &searc
@@ -9070,6 +9070,66 @@ size_t TypeSystemClang::DeclGetFunctionNumArguments(void
*opaque_decl) {
return 0;
}
+static CompilerContextKind GetCompilerKind(clang::Decl::Kind clang_kind,
+ clang::DeclContext *decl_ctx) {
--
davemgreen wrote:
I don't believe the undef is the issue - I think the issue is that
AArch64InstrInfo::isCopyInstrImpl is saying that a W-reg orr is a copy, even if
it is really a zextend because the entire X output register is depended upon.
Can you try and add something to isCopyInstImpl ins
@@ -0,0 +1,287 @@
+// RUN: %clang_cc1 -std=c2x -verify -triple x86_64 -pedantic -Wno-conversion
-Wno-constant-conversion -Wno-div-by-zero %s
+
+// Check that constexpr only applies to variables.
+constexpr void f0() {} // expected-error {{'constexpr' can only be used in
variable
to268 wrote:
I have found no major issues with the C23 `auto` keyword.
There is a minor improvement that I've found in the test cases.
Concerning N3006 (AKA: Underspecified object declarations), I haven't reviewed
yet the compatibility with the `constexpr` keyword, since I haven't work much
on
@@ -1984,84 +1984,75 @@ void ValueObject::GetExpressionPath(Stream &s,
}
}
-ValueObjectSP ValueObject::GetValueForExpressionPath(
-llvm::StringRef expression, ExpressionPathScanEndReason *reason_to_stop,
-ExpressionPathEndResultType *final_value_type,
+std::optional
https://github.com/Michael137 approved this pull request.
LGTM (just left some small comments)
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lld
https://github.com/Michael137 edited
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -64,6 +64,125 @@ bool
lldb_private::contextMatches(llvm::ArrayRef context_chain,
return true;
}
+static CompilerContextKind ConvertTypeClass(lldb::TypeClass type_class) {
+ if (type_class == eTypeClassAny)
+return CompilerContextKind::AnyType;
+ uint16_t result = 0
@@ -64,6 +64,125 @@ bool
lldb_private::contextMatches(llvm::ArrayRef context_chain,
return true;
}
+static CompilerContextKind ConvertTypeClass(lldb::TypeClass type_class) {
+ if (type_class == eTypeClassAny)
+return CompilerContextKind::AnyType;
+ uint16_t result = 0
@@ -263,13 +252,6 @@ TagDecl *ClangASTSource::FindCompleteType(const TagDecl
*decl) {
TagDecl *candidate_tag_decl = const_cast(tag_type->getDecl());
- // We have found a type by basename and we need to make sure the decl
- // contexts are the same before we c
bulbazord wrote:
Is this extension to the protocol documented anywhere I can see? Or is this an
ad-hoc thing? I think it would be useful to write down somewhere other than a
commit message (in docs, comments, or otherwise) that this is an extension.
https://github.com/llvm/llvm-project/pull/74
@@ -1209,6 +1209,15 @@ def G_FENCE : GenericInstruction {
let hasSideEffects = true;
}
+// Generic opcode equivalent to the llvm.prefetch intrinsic.
+def G_PREFETCH : GenericInstruction {
+ let OutOperandList = (outs);
+ let InOperandList = (ins ptype0:$address, i32imm:$rw
https://github.com/H-G-Hristov updated
https://github.com/llvm/llvm-project/pull/74994
>From 6e26ca239c49e1b7d9ab72217db7339e92df163f Mon Sep 17 00:00:00 2001
From: Zingam
Date: Sun, 10 Dec 2023 14:16:02 +0200
Subject: [PATCH 01/11] [libc++][span] P2821R5: span.at()
---
libcxx/include/span
walter-erquinigo wrote:
> Is this extension to the protocol documented anywhere I can see? Or is this
> an ad-hoc thing? I think it would be useful to write down somewhere other
> than a commit message (in docs, comments, or otherwise) that this is an
> extension.
@bulbazord , it's an ad hoc
bulbazord wrote:
> `{${function.is-optimized} [opt]}` is how is already is and can be done with
> frame formats, so I agree with this patch that if the user customizes it,
> they have complete control and we shouldn't add anything. Does everyone else
> agree?
I think I agree with this in prin
bulbazord wrote:
> > Is this extension to the protocol documented anywhere I can see? Or is this
> > an ad-hoc thing? I think it would be useful to write down somewhere other
> > than a commit message (in docs, comments, or otherwise) that this is an
> > extension.
>
> @bulbazord , it's an ad
https://github.com/bulbazord approved this pull request.
https://github.com/llvm/llvm-project/pull/74865
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/H-G-Hristov updated
https://github.com/llvm/llvm-project/pull/74994
>From 6e26ca239c49e1b7d9ab72217db7339e92df163f Mon Sep 17 00:00:00 2001
From: Zingam
Date: Sun, 10 Dec 2023 14:16:02 +0200
Subject: [PATCH 01/12] [libc++][span] P2821R5: span.at()
---
libcxx/include/span
@@ -1859,17 +1851,11 @@ lldb::SBTypeList SBTarget::FindTypes(const char
*typename_cstr) {
if (typename_cstr && typename_cstr[0] && target_sp) {
ModuleList &images = target_sp->GetImages();
ConstString const_typename(typename_cstr);
-bool exact_match = false;
-
@@ -1696,16 +1696,16 @@ static size_t LookupTypeInModule(Target *target,
CommandInterpreter &interpreter, Stream &strm,
Module *module, const char *name_cstr,
bool name_is_regex)
@@ -146,6 +133,9 @@ class TypeSystem : public PluginInterface,
virtual CompilerDeclContext
GetCompilerDeclContextForType(const CompilerType &type);
+ virtual std::vector
+ DeclContextGetCompilerContext(void *opaque_decl_ctx);
clayborg wrote:
I would rat
@@ -122,6 +106,9 @@ class TypeSystem : public PluginInterface,
virtual CompilerType DeclGetFunctionArgumentType(void *opaque_decl,
size_t arg_idx);
+ virtual std::vector
+ DeclGetCompilerContext(void *opaque_decl);
---
@@ -1446,23 +1446,23 @@ void SymbolFilePDB::AddSymbols(lldb_private::Symtab
&symtab) {
symtab.Finalize();
}
-void SymbolFilePDB::FindTypes(
-lldb_private::ConstString name, const CompilerDeclContext &parent_decl_ctx,
-uint32_t max_matches,
-llvm::DenseSet &searc
@@ -12,33 +12,32 @@ class UniqueTypesTestCase4(TestBase):
def do_test(self, debug_flags):
"""Test that we display the correct template instantiation."""
self.build(dictionary=debug_flags)
+exe = self.getBuildArtifact("a.out")
+print(exe)
@@ -12,33 +12,32 @@ class UniqueTypesTestCase4(TestBase):
def do_test(self, debug_flags):
"""Test that we display the correct template instantiation."""
self.build(dictionary=debug_flags)
+exe = self.getBuildArtifact("a.out")
+print(exe)
@@ -343,6 +345,15 @@ public:
return __data_[__idx];
}
+# if _LIBCPP_STD_VER >= 26
+_LIBCPP_HIDE_FROM_ABI constexpr reference at(size_type __index) const {
+ if (__index >= size()) {
H-G-Hristov wrote:
Done! Sorry I missed that.
https://
@@ -64,6 +64,125 @@ bool
lldb_private::contextMatches(llvm::ArrayRef context_chain,
return true;
}
+static CompilerContextKind ConvertTypeClass(lldb::TypeClass type_class) {
+ if (type_class == eTypeClassAny)
+return CompilerContextKind::AnyType;
+ uint16_t result = 0
@@ -64,6 +64,125 @@ bool
lldb_private::contextMatches(llvm::ArrayRef context_chain,
return true;
}
+static CompilerContextKind ConvertTypeClass(lldb::TypeClass type_class) {
+ if (type_class == eTypeClassAny)
+return CompilerContextKind::AnyType;
+ uint16_t result = 0
@@ -122,6 +106,9 @@ class TypeSystem : public PluginInterface,
virtual CompilerType DeclGetFunctionArgumentType(void *opaque_decl,
size_t arg_idx);
+ virtual std::vector
+ DeclGetCompilerContext(void *opaque_decl);
---
@@ -2225,7 +2225,8 @@ void ObjectFileMachO::ParseSymtab(Symtab &symtab) {
const char *file_name = file.GetFilename().AsCString("");
LLDB_SCOPED_TIMERF("ObjectFileMachO::ParseSymtab () module = %s", file_name);
LLDB_LOG(log, "Parsing symbol table for {0}", file_name);
- P
Michael137 wrote:
BTW, lets prefix the commit with `[lldb]` before merging
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
bulbazord wrote:
@compnerd Perhaps you can take a look at this one? Not sure who does Windows
work on LLDB these days.
https://github.com/llvm/llvm-project/pull/74731
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi
https://github.com/walter-erquinigo closed
https://github.com/llvm/llvm-project/pull/74861
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Walter Erquinigo
Date: 2023-12-11T14:46:25-05:00
New Revision: 07ed3258d0b38bdfd60c203c23a59c8ce8def914
URL:
https://github.com/llvm/llvm-project/commit/07ed3258d0b38bdfd60c203c23a59c8ce8def914
DIFF:
https://github.com/llvm/llvm-project/commit/07ed3258d0b38bdfd60c203c23a59c8ce8def914.di
@@ -2225,7 +2225,8 @@ void ObjectFileMachO::ParseSymtab(Symtab &symtab) {
const char *file_name = file.GetFilename().AsCString("");
LLDB_SCOPED_TIMERF("ObjectFileMachO::ParseSymtab () module = %s", file_name);
LLDB_LOG(log, "Parsing symbol table for {0}", file_name);
- P
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/69516
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -2225,7 +2225,8 @@ void ObjectFileMachO::ParseSymtab(Symtab &symtab) {
const char *file_name = file.GetFilename().AsCString("");
LLDB_SCOPED_TIMERF("ObjectFileMachO::ParseSymtab () module = %s", file_name);
LLDB_LOG(log, "Parsing symbol table for {0}", file_name);
- P
clayborg wrote:
> @clayborg , I actually insist on aborting on failure for this feature. You
> mention:
>
> > It would be nice if the RunLLDBCommands function could take an extra bool
> > &fatal_error that clients could check after running when needed to decide
> > what to do if this is set t
Author: Walter Erquinigo
Date: 2023-12-11T15:20:06-05:00
New Revision: 0ea19bdaf71dd3aaf7c0a6ef9a0930958c12
URL:
https://github.com/llvm/llvm-project/commit/0ea19bdaf71dd3aaf7c0a6ef9a0930958c12
DIFF:
https://github.com/llvm/llvm-project/commit/0ea19bdaf71dd3aaf7c0a6ef9a0930958c12.di
https://github.com/walter-erquinigo closed
https://github.com/llvm/llvm-project/pull/74865
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/74865
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1165,6 +1188,24 @@ llvm::json::Value CreateVariable(lldb::SBValue v,
int64_t variablesReference,
const char *evaluateName = evaluateStream.GetData();
if (evaluateName && evaluateName[0])
EmplaceSafeString(object, "evaluateName", std::string(evaluateName));
+
+ if
https://github.com/clayborg commented:
Might be good idea to only add "declaration" if and only if we have both a file
and line at least?
https://github.com/llvm/llvm-project/pull/74865
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https:/
@@ -1165,6 +1188,24 @@ llvm::json::Value CreateVariable(lldb::SBValue v,
int64_t variablesReference,
const char *evaluateName = evaluateStream.GetData();
if (evaluateName && evaluateName[0])
EmplaceSafeString(object, "evaluateName", std::string(evaluateName));
+
+ if
walter-erquinigo wrote:
> Might be good idea to only add "declaration" if and only if we have both a
> file and line at least?
I think it's better to emit it if there's at least one of them. We can leave it
to the client the decision of what to do if only one of them is available.
https://git
walter-erquinigo wrote:
> "error: one of your required 'attachCommands' failed, check the debug console
> for details"
This is a key thing that I didn't consider in the beginning. I'm going to
update this patch to only support `?`, and then I'll make another one for `!`,
because I need to exp
https://github.com/augusto2112 created
https://github.com/llvm/llvm-project/pull/75102
The newly introduced LocationListLookupTestCase.test_loclist_expr test fails
with older clangs.
>From 0ec0f8ddf505ad30f8684e9452ebc4524f50a4b4 Mon Sep 17 00:00:00 2001
From: Augusto Noronha
Date: Mon, 11 De
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Augusto Noronha (augusto2112)
Changes
The newly introduced LocationListLookupTestCase.test_loclist_expr test fails
with older clangs.
---
Full diff: https://github.com/llvm/llvm-project/pull/75102.diff
1 Files Affected:
- (modified)
ll
https://github.com/ChipsSpectre updated
https://github.com/llvm/llvm-project/pull/74926
>From 8269060e6b50721a847742ff8d0af2c819e52578 Mon Sep 17 00:00:00 2001
From: ChipsSpectre
Date: Sat, 9 Dec 2023 12:07:02 +0100
Subject: [PATCH 1/2] fix issue 73559.
---
clang/lib/Parse/ParseDecl.cpp|
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r
13ef4fec26650a93b57709a23a3392582825afe7...0ec0f8ddf505ad30f8684e9452ebc4524f50a4b4
lldb/
https://github.com/ChipsSpectre updated
https://github.com/llvm/llvm-project/pull/74926
>From 8269060e6b50721a847742ff8d0af2c819e52578 Mon Sep 17 00:00:00 2001
From: ChipsSpectre
Date: Sat, 9 Dec 2023 12:07:02 +0100
Subject: [PATCH 1/2] fix issue 73559.
---
clang/lib/Parse/ParseDecl.cpp|
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff f92d970c8cc27747478abb7df66bb8b6701cea49
e8419c3750f7b1cf877b042942204abaab48344b --
https://github.com/ChipsSpectre updated
https://github.com/llvm/llvm-project/pull/74926
>From 8269060e6b50721a847742ff8d0af2c819e52578 Mon Sep 17 00:00:00 2001
From: ChipsSpectre
Date: Sat, 9 Dec 2023 12:07:02 +0100
Subject: [PATCH 1/3] fix issue 73559.
---
clang/lib/Parse/ParseDecl.cpp|
https://github.com/augusto2112 updated
https://github.com/llvm/llvm-project/pull/75102
>From be91ba6b5b411e2fc6b9a7b49324ef5b20c9e2ed Mon Sep 17 00:00:00 2001
From: Augusto Noronha
Date: Mon, 11 Dec 2023 13:38:04 -0800
Subject: [PATCH] [lldb] Disable new TestLocationListLookup when clang versio
rnk wrote:
@david-xl , Zequan posted an
[RFC](https://discourse.llvm.org/t/rfc-add-binary-profile-correlation-to-not-load-profile-metadata-sections-into-memory-at-runtime/74565/8)
for this. Is there a PGO tag, or something we can use to increase visibility
for PGO reviewers? I think most of th
jimingham wrote:
> > Note, I thought about adding an `SBDebugger::GetSharedModules or something,
> > but I don't actually think that's a good thing to give external access to.
> > Some day we should make an SBTestAPI with some useful for testing but not
> > for the SB API library so we can mak
Author: Augusto Noronha
Date: 2023-12-11T14:40:43-08:00
New Revision: a37fa2a8e1c827f1ff04b0b13b83cf97eefe74c0
URL:
https://github.com/llvm/llvm-project/commit/a37fa2a8e1c827f1ff04b0b13b83cf97eefe74c0
DIFF:
https://github.com/llvm/llvm-project/commit/a37fa2a8e1c827f1ff04b0b13b83cf97eefe74c0.dif
https://github.com/augusto2112 closed
https://github.com/llvm/llvm-project/pull/75102
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/ChipsSpectre updated
https://github.com/llvm/llvm-project/pull/74926
>From 8269060e6b50721a847742ff8d0af2c819e52578 Mon Sep 17 00:00:00 2001
From: ChipsSpectre
Date: Sat, 9 Dec 2023 12:07:02 +0100
Subject: [PATCH 1/4] fix issue 73559.
---
clang/lib/Parse/ParseDecl.cpp|
ChipsSpectre wrote:
The pull request is updated now, and passing tests and formatting checks.
Is it ready to be merged in its new state?
https://github.com/llvm/llvm-project/pull/74926
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/74894
>From 438d35a7a7fca454718062583f91776ca018b2b1 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Fri, 8 Dec 2023 14:43:14 -0800
Subject: [PATCH 1/2] Add a test for evicting unreachable modules from the
global mo
jimingham wrote:
I added a test for the case where one target has the old version and another
target has the new one. In this case, I don't think (short of
MemoryPressureDetected by hand) that we'll ever get rid of these unreachable
Modules.
https://github.com/llvm/llvm-project/pull/74894
__
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r
44dc1e0baae7c4b8a02ba06dcf396d3d452aa873...684cee4a363c87c6b2cfa0776adb7c5923a0f6b6
lldb/
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 42bba97fc24f045f593fc26f998bac9b08633255
9e826b1fc9dcc25186a9e7aef0998aab4978cfca --
david-xl wrote:
> @david-xl , Zequan posted an
> [RFC](https://discourse.llvm.org/t/rfc-add-binary-profile-correlation-to-not-load-profile-metadata-sections-into-memory-at-runtime/74565/8)
> for this. Is there a PGO tag, or something we can use to increase visibility
> for PGO reviewers? I thi
Author: David Blaikie
Date: 2023-12-12T00:07:08Z
New Revision: 2e197602305be18b963928e6ae024a004a95af6d
URL:
https://github.com/llvm/llvm-project/commit/2e197602305be18b963928e6ae024a004a95af6d
DIFF:
https://github.com/llvm/llvm-project/commit/2e197602305be18b963928e6ae024a004a95af6d.diff
LOG:
MaskRay wrote:
We have this team: @llvm/pr-subscribers-pgo
https://github.com/llvm/llvm-project/pull/69493
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg wrote:
> BTW, lets prefix the commit with `[lldb]` before merging
Do we need to fix this in the commit message when I squash? Or do I just update
the title of this PR?
https://github.com/llvm/llvm-project/pull/74786
___
lldb-commits mailing
clayborg wrote:
> > > Sorry, it's been a while since I last reviewed this and I must admit I
> > > forgot about this in the mean time. The only thing I'd like to check
> > > before we can land this is to hear from @Michael137 who has been actively
> > > working on FindTypes performance recentl
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/74894
>From 438d35a7a7fca454718062583f91776ca018b2b1 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Fri, 8 Dec 2023 14:43:14 -0800
Subject: [PATCH 1/3] Add a test for evicting unreachable modules from the
global mo
@@ -175,3 +179,30 @@ Status TargetThreadWindows::DoResume() {
return Status();
}
+
+const char *TargetThreadWindows::GetName() {
+ Log *log = GetLog(LLDBLog::Thread);
+ HMODULE hModule = ::LoadLibraryW(L"Kernel32.dll");
+ if (hModule) {
+auto GetThreadDescription =
--
@@ -175,3 +179,30 @@ Status TargetThreadWindows::DoResume() {
return Status();
}
+
+const char *TargetThreadWindows::GetName() {
+ Log *log = GetLog(LLDBLog::Thread);
+ HMODULE hModule = ::LoadLibraryW(L"Kernel32.dll");
+ if (hModule) {
+auto GetThreadDescription =
+
@@ -175,3 +179,30 @@ Status TargetThreadWindows::DoResume() {
return Status();
}
+
+const char *TargetThreadWindows::GetName() {
+ Log *log = GetLog(LLDBLog::Thread);
+ HMODULE hModule = ::LoadLibraryW(L"Kernel32.dll");
+ if (hModule) {
+auto GetThreadDescription =
+
kevinfrei wrote:
Is there some documentation that both me & google are missing somewhere? I'm
trying to read between the lines of the scenario that's broken, with nothing
but a log (that refers to a bunch of pretty important configuration files from
somewhere I can't find) with a repo configur
1 - 100 of 105 matches
Mail list logo
