@@ -26,17 +26,19 @@ ScriptInterpreterNone::ScriptInterpreterNone(Debugger
&debugger)
ScriptInterpreterNone::~ScriptInterpreterNone() = default;
+static const char *no_interpreter_err_msg =
+"There is no embedded script interpreter. Check that LLDB was built with a
"
+
=?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:
medismailben wrote:
Guys, this sounds very cool, but I don't think I've seen any screenshot of what
=?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:
 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
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
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
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 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
@@ -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 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+++.
bulbazord wrote:
If
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
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
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
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
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`.
@@ -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
@@ -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
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
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/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
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/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
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/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
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/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
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 --
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
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
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
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
_
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
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-
@@ -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
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
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
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
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
@@ -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
@@ -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
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
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
@@ -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
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
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
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
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
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 --
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
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
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/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
@@ -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/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
@@ -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
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
___
89 matches
Mail list logo
