Michael137 wrote:
> Can we add back the constant to the declaration? It's been a week and the
> progress on #72730 seems to have stalled while our builders are still broken.
Yup will do, apologies for the noise
https://github.com/llvm/llvm-project/pull/71780
___
@@ -1926,12 +1930,13 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext &sc,
// TypeSystemClang is always in C++ mode, but some compilers such as
// GCC and Clang give empty structs a size of 0 in C mode (in contrast to
// the size of 1 for emp
https://github.com/rupprecht updated
https://github.com/llvm/llvm-project/pull/73028
>From a0805cfc2b2b1c84d58c0551ccf1acfaf2326a4a Mon Sep 17 00:00:00 2001
From: Jordan Rupprecht
Date: Tue, 21 Nov 2023 11:38:43 -0800
Subject: [PATCH 1/3] [lldb][test] Remove `reason` from
`unittest2.expectedFa
@@ -32,8 +32,8 @@ Progress::~Progress() {
std::lock_guard guard(m_mutex);
if (!m_completed) {
m_completed = m_total;
-ReportProgress();
}
medismailben wrote:
Remove the braces:
https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simp
https://github.com/medismailben edited
https://github.com/llvm/llvm-project/pull/73605
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/medismailben approved this pull request.
LGTM with comment.
https://github.com/llvm/llvm-project/pull/73605
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Chelsea Cassanova (chelcassanova)
Changes
This commit allows a final progress report upon the destruction of the
`Progress` object to happen at all times as opposed to when the progress was
not completed.
---
Full diff: https://github.com
https://github.com/chelcassanova created
https://github.com/llvm/llvm-project/pull/73605
This commit allows a final progress report upon the destruction of the
`Progress` object to happen at all times as opposed to when the progress was
not completed.
>From 8c29a2034a57174ec68f8c1f1a2c5c66a79
jimingham wrote:
I would prefer you make the `-t` an option with a value, rather than a flag
saying what the argument means. It makes the completer much easier to hook up
since the option value can complete against the native thread ID's, and the
argument complete against thread indexes. You
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 67268da61aa2f8b24172907ee6f8d9250ee18b65
97a6e23c85457a14c91c5800fa03bb872e6f1fa6 --
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Michael Christensen (mdko)
Changes
We'd like a way to select the current thread by its thread ID (rather than its
internal LLDB thread index).
This PR adds a `-t` option (`--thread_id` long option) that tells the `thread
select` command t
mdko wrote:
CC @jeffreytan81 @clayborg
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/mdko created https://github.com/llvm/llvm-project/pull/73596
We'd like a way to select the current thread by its thread ID (rather than its
internal LLDB thread index).
This PR adds a `-t` option (`--thread_id` long option) that tells the `thread
select` command to interpret
https://github.com/clayborg approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/73307
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1926,12 +1930,13 @@ DWARFASTParserClang::ParseStructureLikeDIE(const
SymbolContext &sc,
// TypeSystemClang is always in C++ mode, but some compilers such as
// GCC and Clang give empty structs a size of 0 in C mode (in contrast to
// the size of 1 for emp
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/73307
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Nico Weber
Date: 2023-11-28T08:53:05+09:00
New Revision: a6c62bf1a4717accc852463b664cd1012237d334
URL:
https://github.com/llvm/llvm-project/commit/a6c62bf1a4717accc852463b664cd1012237d334
DIFF:
https://github.com/llvm/llvm-project/commit/a6c62bf1a4717accc852463b664cd1012237d334.diff
LO
petrhosek wrote:
Can we add back the constant to the declaration? It's been a week and the
progress on #72730 seems to have stalled while our builders are still broken.
https://github.com/llvm/llvm-project/pull/71780
___
lldb-commits mailing list
lldb
@@ -194,6 +192,54 @@ class CompilerType {
bool IsTypedefType() const;
bool IsVoidType() const;
+
+ bool IsSmartPtrType() const;
adrian-prantl wrote:
Some methods like this one could benefit from a Doxygen comment that explains
what the semantics are.
h
@@ -194,6 +192,54 @@ class CompilerType {
bool IsTypedefType() const;
bool IsVoidType() const;
+
+ bool IsSmartPtrType() const;
+
+ bool IsInteger() const;
+
+ bool IsFloat() const;
+
+ bool IsEnumerationType() const;
+
+ bool IsUnscopedEnumerationType() const;
+
+ b
@@ -194,6 +192,54 @@ class CompilerType {
bool IsTypedefType() const;
bool IsVoidType() const;
+
+ bool IsSmartPtrType() const;
+
+ bool IsInteger() const;
+
+ bool IsFloat() const;
+
+ bool IsEnumerationType() const;
+
+ bool IsUnscopedEnumerationType() const;
+
+ b
dyung wrote:
> Seems that it caused #73580 no?
I believe so. @jasonmolenda I see you attempted to make a fix in
a0a1ff3ab40e347589b4e27d8fd350c600526735, however I still have two buildbots
that are failing to build. Can you either fix it or revert if you need time to
investigate?
https://lab
jyknight wrote:
I guess I'd consider the "mental model" here to be that (notionally) `#embed`
is preprocessed by expanding to `#embed_base64`, which is handled by the
compiler proper, not the preprocessor. Yes, that's not entirely true in the
implementation, but it seems like a reasonable way
rupprecht wrote:
> I suppose we don't really lose anything by moving away from `expectedFailure`
> from decorators?
>
Someone filed a FR ages ago for the standard unittest to take a reason for
xfail: https://bugs.python.org/issue12681
tl;dr good idea but that ship has sailed. So, this PR isn
rupprecht wrote:
> * This is still early enough that the standard `unittest` framework will
> recognize the test as xfail/skip by the time the test actually runs.
I did a little bit more research, turns out this is not a difference between
unittest and unittest2, but rather just something we h
@@ -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
@@ -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
@@ -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
sylvestre wrote:
Seems that it caused https://github.com/llvm/llvm-project/issues/73580 no?
https://github.com/llvm/llvm-project/pull/68845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-
AaronBallman wrote:
> I'm somewhat concerned about the default for `-E` being to explode `#embed`
> into the comma-separated raw integers. Even with moderately-sized embeds, I
> think it'll generate unusably-bloated output. The human-readability of a big
> list of integers is not better than e
madanial0 wrote:
> I see you re-based 2 times. Does this look Ok as is? It would be good to add
> the AIX Driver bits once this goes in.
This should be good as is pending any review comments/approvals
https://github.com/llvm/llvm-project/pull/73254
_
https://github.com/PortalPete updated
https://github.com/llvm/llvm-project/pull/72150
>From af3e1a6dce00477afd1418cc41fde6a2f8c17258 Mon Sep 17 00:00:00 2001
From: Pete Lawrence
Date: Mon, 6 Nov 2023 17:16:28 -1000
Subject: [PATCH] Remove secondary "error: " and print diagnostic line with
care
brad0 wrote:
I see you re-based 2 times. Does this look Ok as is? It would be good to add
the AIX Driver bits once this goes in.
https://github.com/llvm/llvm-project/pull/73254
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.ll
jyknight wrote:
I'm somewhat concerned about the default for `-E` being to explode `#embed`
into the comma-separated raw integers. Even with moderately-sized embeds, I
think it'll generate unusably-bloated output. The human-readability of a big
list of integers is not better than embedded base
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 a0a1ff3ab40e347589b4e27d8fd350c600526735
047413349901684411fb260a49c996633b7b4dc0 --
https://github.com/PortalPete updated
https://github.com/llvm/llvm-project/pull/72150
>From 047413349901684411fb260a49c996633b7b4dc0 Mon Sep 17 00:00:00 2001
From: Pete Lawrence
Date: Mon, 6 Nov 2023 17:16:28 -1000
Subject: [PATCH] Remove secondary "error: " and print diagnostic line with
care
Author: Jason Molenda
Date: 2023-11-27T13:39:24-08:00
New Revision: a0a1ff3ab40e347589b4e27d8fd350c600526735
URL:
https://github.com/llvm/llvm-project/commit/a0a1ff3ab40e347589b4e27d8fd350c600526735
DIFF:
https://github.com/llvm/llvm-project/commit/a0a1ff3ab40e347589b4e27d8fd350c600526735.diff
https://github.com/silee2 updated
https://github.com/llvm/llvm-project/pull/71430
>From c76403cf8629b8f7d8a5b7a3ee5da2881713a7f8 Mon Sep 17 00:00:00 2001
From: "Lee, Sang Ik"
Date: Mon, 6 Nov 2023 18:47:23 +
Subject: [PATCH 1/5] [MLIR] Enable GPU Dialect to SYCL runtime integration
GPU Dia
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/68845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/JDevlieghere approved this pull request.
I was out last week. Thanks, this LGTM!
https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
AaronBallman wrote:
> Your reasoning works until we have a crash that relies on `#embed` and/or its
> contents.
Agreed, that's the "downsides" I mentioned.
> From what I saw triaging old crashes, crash submitters are conscious if they
> work with proprietary code they can't share even a fragm
https://github.com/spupyrev updated
https://github.com/llvm/llvm-project/pull/72542
error: too big or took too long to generate
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
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.
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/68845
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,142 @@
+//===-- SymbolLocatorDebuginfod.cpp
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,37 @@
+//===-- StopPointSiteList.cpp
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
AaronBallman 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://github.com/walter-erquinigo approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/73393
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
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
AaronBallman wrote:
> @AaronBallman Can you describe your current plan how driver options are going
> to behave in the light of `#embed`?
I'm flexible with how we proceed, so if others have different ideas, feel free
to suggest them! But my initial inclination is:
* `--embed-dir=` as a way to
https://github.com/junior-jl updated
https://github.com/llvm/llvm-project/pull/69422
From c416443a93f7113a7f57d337682ec4862438522d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20L=2E=20Junior?=
Date: Tue, 7 Nov 2023 16:57:18 -0300
Subject: [PATCH 1/2] [lldb] colorize symbols in image look
@@ -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+++.
bulbazord wrote:
If
@@ -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
https://github.com/bulbazord commented:
Seems okay to me in general. Left some inline comments and I also agree with
all of Jonas's inline comments I saw too.
https://github.com/llvm/llvm-project/pull/73472
___
lldb-commits mailing list
lldb-commits@
@@ -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
https://github.com/bulbazord edited
https://github.com/llvm/llvm-project/pull/73472
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/junior-jl updated
https://github.com/llvm/llvm-project/pull/69422
From c416443a93f7113a7f57d337682ec4862438522d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20L=2E=20Junior?=
Date: Tue, 7 Nov 2023 16:57:18 -0300
Subject: [PATCH 1/2] [lldb] colorize symbols in image look
https://github.com/bulbazord approved this pull request.
Lgtm thanks!
https://github.com/llvm/llvm-project/pull/73393
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
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:
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
@@ -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
@@ -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
@@ -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
https://github.com/madanial0 updated
https://github.com/llvm/llvm-project/pull/73254
>From 81d1e05dd084dd5bb88dab88d2f23008b8dc6cfb Mon Sep 17 00:00:00 2001
From: Mark Danial
Date: Tue, 21 Nov 2023 12:18:40 -0500
Subject: [PATCH] Pass the correct path to getIntriniscDir and
getOpenMPHeadersDir
shahidiqbal13 wrote:
Hi @DrTodd13 ,
Any further needs to be done here ?? Can you please add more devs for reviewing
this
Thanks,
Shahid
https://github.com/llvm/llvm-project/pull/72654
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https:
Author: David Spickett
Date: 2023-11-27T09:10:56Z
New Revision: 772f296214e10323ca16921c02b1852307b7d51b
URL:
https://github.com/llvm/llvm-project/commit/772f296214e10323ca16921c02b1852307b7d51b
DIFF:
https://github.com/llvm/llvm-project/commit/772f296214e10323ca16921c02b1852307b7d51b.diff
LOG
https://github.com/DavidSpickett closed
https://github.com/llvm/llvm-project/pull/73321
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: David Spickett
Date: 2023-11-27T09:10:39Z
New Revision: 8167934480a7b6a8e122aa6233aa8ed2e2683d6a
URL:
https://github.com/llvm/llvm-project/commit/8167934480a7b6a8e122aa6233aa8ed2e2683d6a
DIFF:
https://github.com/llvm/llvm-project/commit/8167934480a7b6a8e122aa6233aa8ed2e2683d6a.diff
LOG
https://github.com/DavidSpickett updated
https://github.com/llvm/llvm-project/pull/73321
>From bc00c8f219134554d2dcbcb39e7565797c1ed14c Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Fri, 24 Nov 2023 12:05:41 +
Subject: [PATCH] [lldb] Improve error message for script commands when ther
medismailben wrote:
Seems to have been resolved in #72669
https://github.com/llvm/llvm-project/pull/72579
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/medismailben closed
https://github.com/llvm/llvm-project/pull/72579
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
=?utf-8?q?José?= L. Junior ,taalhaataahir0102
<23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior ,
=?utf-8?q?José?= L. Junior ,taalhaataahir0102
<23100...@lums.edu.pk>
Message-ID:
In-Reply-To:
taalhaataahir0102 wrote:
Hi! This is how the implemented version looks like:
ScriptInterpreterNone::~ScriptInterpreterNone() = default;
+static const char *no_interpreter_err_msg =
+"There is no embedded script interpreter. Check that LLDB was built with a
"
+
89 matches
Mail list logo
