@@ -313,6 +313,8 @@ class TypeImpl {
bool GetDescription(lldb_private::Stream &strm,
lldb::DescriptionLevel description_level);
+ CompilerType FindNestedType(ConstString name);
Endilll wrote:
> Do we want to make a ConstString for eve
Endilll wrote:
@jimingham
https://github.com/llvm/llvm-project/blob/d5444ab26743115e42e4abb3782bbefb0e8912d0/lldb/source/Symbol/CompilerDeclContext.cpp#L49-L61
and
https://github.com/llvm/llvm-project/blob/d5444ab26743115e42e4abb3782bbefb0e8912d0/lldb/source/Plugins/TypeSystem/Clang/TypeSystemCla
https://github.com/fel-cab updated
https://github.com/llvm/llvm-project/pull/68016
>From dd44de067c26ba94b6561c5ed7fa4a5d812a3d1a Mon Sep 17 00:00:00 2001
From: Felipe Cabarcas
Date: Mon, 18 Sep 2023 12:07:12 +
Subject: [PATCH 01/13] testing Profiler features
---
openmp/libomptarget/src/i
shraiysh wrote:
Sure I'll do that.
https://github.com/llvm/llvm-project/pull/65243
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jimingham wrote:
Just to make sure I understand. You're using FindTypes in a DeclContext using
max_matches == 1. But FindTypes will recurse in the DeclContext, so depending
on the actual search implementation, you could have a situation like:
```
class A {
class B {
class C {
Endilll wrote:
> find A::B::C which is a match, note max_matches == 1 and return
Looking at `DeclContextIsContainedInLookup`, `A::B::C` is not a match, because
it's `DeclContext` is not `DeclContext` of `A`. This is of course is not
future-proof against changes to `DeclContextIsContainedInLook
https://github.com/shraiysh created
https://github.com/llvm/llvm-project/pull/68825
This patch adds `omp.structured_region` operation. This is equivalent to a code
block surrounded by an OpenMP construct in C/C++/Fortran. This is a part of the
effort to implement the canonical loop operation i
llvmbot wrote:
@llvm/pr-subscribers-mlir
Author: Shraiysh (shraiysh)
Changes
This patch adds `omp.structured_region` operation. This is equivalent to a code
block surrounded by an OpenMP construct in C/C++/Fortran. This is a part of the
effort to implement the canonical loop operation in
shraiysh wrote:
Restarting discussion about yield here because something went wrong with
rebasing on previous PR. Hopefully this won't have the same issues. Sorry :(
I will push commit with yield as terminator soon.
https://github.com/llvm/llvm-project/pull/68825
__
jimingham wrote:
Yes, if this API is going to claim to only find directly contained types, there
needs to be an explicit guarantee that that's what the underlying API's do.
The API you call should state that it is doing that, and you also need to write
tests that make sure we only see direct
https://github.com/shraiysh updated
https://github.com/llvm/llvm-project/pull/68825
>From ff635ce0ce910f0cde248a4babb3c27333ddc108 Mon Sep 17 00:00:00 2001
From: Shraiysh Vaishay
Date: Sun, 3 Sep 2023 22:40:10 -0500
Subject: [PATCH 1/3] [mlir][OpenMP] Added omp.region operation
This patch adds
Endilll wrote:
It's not clear to me whether `TypeSystem::DeclContextIsContainedInLookup`
provides such a guarantee. Implementation suggests that it's only interested in
direct `DeclContext`, maybe ignoring transparent decl contexts like inline
namespace it already handles. I hope reviewers can
fel-cab wrote:
I have prepared a presentation to better explain the proposed changes
https://docs.google.com/presentation/d/1lLlR7g29MWidaX9BLCUaKZhdvN-dphUE2BGMXhZCIoA/edit?usp=sharing
https://github.com/llvm/llvm-project/pull/68016
___
lldb-commits m
jimingham wrote:
> It's not clear to me whether `TypeSystem::DeclContextIsContainedInLookup`
> provides such a guarantee. Implementation suggests that it's only interested
> in direct `DeclContext`, maybe ignoring transparent decl contexts like inline
> namespace it already handles. I hope rev
https://github.com/clayborg approved this pull request.
I will trust this info is correct!
https://github.com/llvm/llvm-project/pull/68234
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-co
https://github.com/clayborg commented:
Should we have a top level "lldb_plugin" namespace instead of
"lldb_private::plugin"? It would be easier to be able to export only a single
plug-in interface if needed if we did this
https://github.com/llvm/llvm-project/pull/68150
Author: Walter Erquinigo
Date: 2023-10-11T16:39:35-04:00
New Revision: 098c92777ee434a7e395d293153403ffebc936d8
URL:
https://github.com/llvm/llvm-project/commit/098c92777ee434a7e395d293153403ffebc936d8
DIFF:
https://github.com/llvm/llvm-project/commit/098c92777ee434a7e395d293153403ffebc936d8.di
https://github.com/walter-erquinigo closed
https://github.com/llvm/llvm-project/pull/68234
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
walter-erquinigo wrote:
@clayborg has a very valid point. This will allow for better tuning of what
gets exported. I'll do that instead.
https://github.com/llvm/llvm-project/pull/68150
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://
clayborg wrote:
very nice! Thanks for doing all of our suggested improvements, great patch. I
would love to see a new API in SBTarget that exposes this feature:
```
lldb::SBBreakpoint lldb::SBTarget::CreateBreakpointAtUserEntry();
```
https://github.com/llvm/llvm-project/pull/67019
https://github.com/walter-erquinigo updated
https://github.com/llvm/llvm-project/pull/68150
>From 52f91bcf453790f89626b9d597671c17d0102dcb Mon Sep 17 00:00:00 2001
From: walter erquinigo
Date: Mon, 2 Oct 2023 16:56:16 -0400
Subject: [PATCH] [LLDB][NFC] Create a namespace for the DWARF plugin
A
https://github.com/walter-erquinigo edited
https://github.com/llvm/llvm-project/pull/68150
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg commented:
LGTM, anyone else have any objections?
https://github.com/llvm/llvm-project/pull/68150
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1462,6 +1464,87 @@ static bool DumpModuleSymbolFile(Stream &strm, Module
*module) {
return false;
}
+static bool GetSeparateDebugInfoList(StructuredData::Array &list,
+ Module *module) {
+ if (module) {
+if (SymbolFile *symbol_fi
https://github.com/PortalPete updated
https://github.com/llvm/llvm-project/pull/68755
>From b0dfcb5b88fa206ebf238f04061d170035a6 Mon Sep 17 00:00:00 2001
From: Pete Lawrence <34425917+portalp...@users.noreply.github.com>
Date: Tue, 10 Oct 2023 10:59:58 -1000
Subject: [PATCH] [lldb] Fix `po`
https://github.com/PortalPete updated
https://github.com/llvm/llvm-project/pull/68755
>From c32c8770032143ece59ce5a3effcd5ee7a736f71 Mon Sep 17 00:00:00 2001
From: Pete Lawrence <34425917+portalp...@users.noreply.github.com>
Date: Tue, 10 Oct 2023 10:59:58 -1000
Subject: [PATCH] [lldb] Fix `po`
PortalPete wrote:
Thanks for this suggestion, @medismailben.
> LGTM overall. I think you can make the test less redundant by using the same
> source file & Makefile for both tests.
I wasn't which is better:
- Multiple files, each with a single test
- Fewer files, each with multiple tests.
Ok,
walter-erquinigo wrote:
@JDevlieghere PTAL :)
https://github.com/llvm/llvm-project/pull/68150
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda created
https://github.com/llvm/llvm-project/pull/68845
This patch is rearranging code a bit to add WatchpointResources to Process. A
WatchpointResource is meant to represent a hardware watchpoint register in the
inferior process. It has an address, a size, a
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jason Molenda (jasonmolenda)
Changes
This patch is rearranging code a bit to add WatchpointResources to Process. A
WatchpointResource is meant to represent a hardware watchpoint register in the
inferior process. It has an address, a size
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 1379a7286e156af2d96cb0f3d8aa8e5c7f56bccd
791fd06fe642f1163c39d79c57c7a6daae2c8ea6 --
31 matches
Mail list logo
