[Lldb-commits] [lldb] [lldb] Add SBType::FindNestedType() function (PR #68705)

2023-10-11 Thread Vlad Serebrennikov via lldb-commits 


@@ -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 every argument that is passed to 
> FindNestedType ?

I'm not sure about LLDB conventions around string types, but I need to create 
`ConstString` every time `FindNestedType` is called, because that's what 
`SymbolFile::FindTypes` expects, which I unconditionally call.

https://github.com/llvm/llvm-project/pull/68705
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add SBType::FindNestedType() function (PR #68705)

2023-10-11 Thread Vlad Serebrennikov via lldb-commits 

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/TypeSystemClang.cpp#L9697-L9712
suggest that depth of the search is type-system-dependent, and that Clang type 
system doesn't do recursive check, save for inline namespaces, which doesn't 
matter for this PR. I don't mind writing an interface for recursive search and 
saying somewhere that depths other that 1 are not yet supported, but I consider 
it outside of this PR (and my use case) to implement recursive search. Does 
this sound good to you, or you'd prefer something along the lines of  
`FindDirectNestedType`?

https://github.com/llvm/llvm-project/pull/68705
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [OpenMP] Improve omp offload profiler (PR #68016)

2023-10-11 Thread via lldb-commits 

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/interface.cpp | 5 -
 openmp/libomptarget/src/private.h | 3 ++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/openmp/libomptarget/src/interface.cpp 
b/openmp/libomptarget/src/interface.cpp
index 5f21b16b3fbfb1e..f64e1e268a3952e 100644
--- a/openmp/libomptarget/src/interface.cpp
+++ b/openmp/libomptarget/src/interface.cpp
@@ -252,7 +252,10 @@ static inline int targetKernel(ident_t *Loc, int64_t 
DeviceId, int32_t NumTeams,
   static_assert(std::is_convertible_v,
 "Target AsyncInfoTy must be convertible to AsyncInfoTy.");
 
-  TIMESCOPE_WITH_IDENT(Loc);
+  //TIMESCOPE_WITH_IDENT(Loc);
+  TIMESCOPE();
+  //TIMESCOPE_WITH_NAME_AND_IDENT("Hello", Loc);
+  //TIMESCOPE_WITH_RTM_AND_IDENT("Hello", Loc);
 
   DP("Entering target region for device %" PRId64 " with entry point " DPxMOD
  "\n",
diff --git a/openmp/libomptarget/src/private.h 
b/openmp/libomptarget/src/private.h
index cbce15b63a3eba2..dc6cd3944233955 100644
--- a/openmp/libomptarget/src/private.h
+++ b/openmp/libomptarget/src/private.h
@@ -433,7 +433,8 @@ class ExponentialBackoff {
   SourceInfo SI(IDENT);
\
   std::string ProfileLocation = SI.getProfileLocation();   
\
   std::string RTM = RegionTypeMsg; 
\
-  llvm::TimeTraceScope TimeScope(__FUNCTION__, ProfileLocation + RTM)
+  llvm::TimeTraceScope TimeScope(ProfileLocation, ProfileLocation + RTM)
+  //llvm::TimeTraceScope TimeScope(__FUNCTION__, ProfileLocation + RTM)
 #else
 #define TIMESCOPE()
 #define TIMESCOPE_WITH_IDENT(IDENT)

>From 92586bca6364100c7511ad38a30f41b0f86dea9c Mon Sep 17 00:00:00 2001
From: Felipe Cabarcas 
Date: Tue, 19 Sep 2023 12:02:53 +
Subject: [PATCH 02/13] Improve Profiler 1

---
 llvm/lib/Support/TimeProfiler.cpp |  2 +-
 openmp/libomptarget/src/interface.cpp | 17 +
 openmp/libomptarget/src/omptarget.cpp | 10 +-
 openmp/libomptarget/src/private.h |  5 +++--
 4 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/llvm/lib/Support/TimeProfiler.cpp 
b/llvm/lib/Support/TimeProfiler.cpp
index 4d625b3eb5b1709..e1458116f64ab47 100644
--- a/llvm/lib/Support/TimeProfiler.cpp
+++ b/llvm/lib/Support/TimeProfiler.cpp
@@ -227,7 +227,7 @@ struct llvm::TimeTraceProfiler {
 J.attribute("ph", "X");
 J.attribute("ts", 0);
 J.attribute("dur", DurUs);
-J.attribute("name", "Total " + Total.first);
+J.attribute("name", "Total: " + Total.first);
 J.attributeObject("args", [&] {
   J.attribute("count", int64_t(Count));
   J.attribute("avg ms", int64_t(DurUs / Count / 1000));
diff --git a/openmp/libomptarget/src/interface.cpp 
b/openmp/libomptarget/src/interface.cpp
index f64e1e268a3952e..b8892cbe689107f 100644
--- a/openmp/libomptarget/src/interface.cpp
+++ b/openmp/libomptarget/src/interface.cpp
@@ -33,14 +33,14 @@ using namespace llvm::omp::target::ompt;
 

 /// adds requires flags
 EXTERN void __tgt_register_requires(int64_t Flags) {
-  TIMESCOPE();
+  //TIMESCOPE();
   PM->RTLs.registerRequires(Flags);
 }
 
 

 /// adds a target shared library to the target execution image
 EXTERN void __tgt_register_lib(__tgt_bin_desc *Desc) {
-  TIMESCOPE();
+  //TIMESCOPE();
   if (PM->maybeDelayRegisterLib(Desc))
 return;
 
@@ -61,7 +61,7 @@ EXTERN void __tgt_init_all_rtls() { PM->RTLs.initAllRTLs(); }
 

 /// unloads a target shared library
 EXTERN void __tgt_unregister_lib(__tgt_bin_desc *Desc) {
-  TIMESCOPE();
+  //TIMESCOPE();
   PM->RTLs.unregisterLib(Desc);
   for (auto &RTL : PM->RTLs.UsedRTLs) {
 if (RTL->unregister_lib) {
@@ -82,7 +82,8 @@ targetData(ident_t *Loc, int64_t DeviceId, int32_t ArgNum, 
void **ArgsBase,
   static_assert(std::is_convertible_v,
 "TargetAsyncInfoTy must be convertible to AsyncInfoTy.");
 
-  TIMESCOPE_WITH_RTM_AND_IDENT(RegionTypeMsg, Loc);
+  //TIMESCOPE_WITH_RTM_AND_IDENT(RegionTypeMsg, Loc);
+  TIMESCOPE_WITH_RTM_AND_IDENT("targetData", Loc);
 
   DP("Entering data %s region for device %" PRId64 " with %d mappings\n",
  RegionName, DeviceId, ArgNum);
@@ -253,9 +254,9 @@ static inline int targetKernel(ident_t *Loc, int64_t 
DeviceId, int32_t NumTeams,
 "Target AsyncInfoTy must be convertible to AsyncInfoTy.");
 
   //TIMESCOPE_WITH_IDENT(Loc);
-  TIMESCOPE();
+  //TIMESCOPE();
   //TIMESCOPE_WITH_NAME_AND_IDENT("Hello", Loc);
-

[Lldb-commits] [lldb] [mlir][OpenMP] Added omp.region operation (PR #65243)

2023-10-11 Thread via lldb-commits 

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

[Lldb-commits] [lldb] [lldb] Add SBType::FindNestedType() function (PR #68705)

2023-10-11 Thread via 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 {
   };
   };
  class C {
  };
};

```

where if we do depth first we could start recursing down B, find A::B::C which 
is a match, note max_matches == 1 and return.  So this is really just 
FindFirstNestedType, I don't think you can make any claim about directness 
given how this is implemented.

I still think the idea of allowing a type search to be limited to a given type 
context is useful.  We usually do "FindWhatever" returning a list, and 
"FindFirstWhatever" returning some not described algorithm's chosen "first" 
match.  It's a little odd to add the "First" w/o the list version, however.

https://github.com/llvm/llvm-project/pull/68705
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add SBType::FindNestedType() function (PR #68705)

2023-10-11 Thread Vlad Serebrennikov via lldb-commits 

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 `DeclContextIsContainedInLookup` that can make 
it smarter in this regard, but we can have something along the lines 
`TypeSystem::DeclContextIsDirectlyContainedInLookup` if we deem it necessary.

For the context, this is the first check search algorithm performs while 
determining a match:
https://github.com/llvm/llvm-project/blob/d5444ab26743115e42e4abb3782bbefb0e8912d0/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L2600
https://github.com/llvm/llvm-project/blob/d5444ab26743115e42e4abb3782bbefb0e8912d0/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L2440


https://github.com/llvm/llvm-project/pull/68705
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [mlir][OpenMP] Added `omp.structured_region` operation (PR #68825)

2023-10-11 Thread via lldb-commits 

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 in OpenMP dialect.

>From ff635ce0ce910f0cde248a4babb3c27333ddc108 Mon Sep 17 00:00:00 2001
From: Shraiysh Vaishay 
Date: Sun, 3 Sep 2023 22:40:10 -0500
Subject: [PATCH 1/2] [mlir][OpenMP] Added omp.region operation

This patch adds omp.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 OpenMP dialect.
---
 mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td | 34 
 mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp  | 15 ++
 mlir/test/Dialect/OpenMP/region.mlir  | 53 +++
 3 files changed, 102 insertions(+)
 create mode 100644 mlir/test/Dialect/OpenMP/region.mlir

diff --git a/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td 
b/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
index b1e1fe00b8594a7..cf5b246178f5d7a 100644
--- a/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
+++ b/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
@@ -1787,4 +1787,38 @@ def ClauseRequiresAttr :
   EnumAttr {
 }
 
+
+def RegionOp : OpenMP_Op<"region"> {
+  let summary = "Encapsulates a region in an OpenMP construct.";
+  let description = [{
+Encapsulates a region surrounded by an OpenMP Construct. The intended use
+of this operation is that within an OpenMP operation's region, there would
+be a single `omp.region` operation and a terminator operation as shown
+below.
+
+```
+// Example with `omp.task`
+omp.task {
+  omp.region {
+call @foo : () -> ()
+  }
+  omp.terminator
+}
+```
+
+This operation is especially more useful in operations that use `omp.yield`
+as a terminator. For example, in the proposed canonical loop operation,
+this operation would help fix the arguments of the yield operation and it
+is not affected by branches in the region assosciated with the canonical
+loop. In cases where the yielded value has to be a compile time constant,
+this provides a mechanism to avoid complex static analysis for the constant
+value.
+  }];
+  let regions = (region AnyRegion:$block);
+  let assemblyFormat = [{
+$block attr-dict
+  }];
+  let hasVerifier = 1;
+}
+
 #endif // OPENMP_OPS
diff --git a/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp 
b/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
index 2ba5f1aca9cf6b2..2a2fcdb788cb99b 100644
--- a/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
+++ b/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
@@ -1524,6 +1524,21 @@ LogicalResult CancellationPointOp::verify() {
   return success();
 }
 
+//===--===//
+// RegionOp
+//===--===//
+
+LogicalResult RegionOp::verify() {
+  Operation *parentOp = (*this)->getParentOp();
+  if (!parentOp)
+return emitOpError() << "`omp.region` must have a parent";
+
+  if (!isa(parentOp->getDialect()))
+return emitOpError()
+   << "`omp.region` must be used under an OpenMP Dialect operation.";
+  return success();
+}
+
 #define GET_ATTRDEF_CLASSES
 #include "mlir/Dialect/OpenMP/OpenMPOpsAttributes.cpp.inc"
 
diff --git a/mlir/test/Dialect/OpenMP/region.mlir 
b/mlir/test/Dialect/OpenMP/region.mlir
new file mode 100644
index 000..4e0ddbc07e9ec9d
--- /dev/null
+++ b/mlir/test/Dialect/OpenMP/region.mlir
@@ -0,0 +1,53 @@
+// RUN: mlir-opt %s | mlir-opt | FileCheck %s
+
+// CHECK-LABEL: @basic_omp_region
+// CHECK-NEXT: omp.parallel {
+// CHECK-NEXT:   omp.region {
+// CHECK-NEXT: "test.foo"() : () -> ()
+// CHECK-NEXT: omp.terminator
+// CHECK-NEXT:   }
+// CHECK-NEXT:   omp.terminator
+// CHECK-NEXT: }
+// CHECK-NEXT: return
+func.func @basic_omp_region() {
+  omp.parallel {
+omp.region {
+  "test.foo"() : () -> ()
+  omp.terminator
+}
+omp.terminator
+  }
+  return
+}
+
+// CHECK-LABEL: @omp_region_with_branch
+// CHECK-NEXT: omp.task {
+// CHECK-NEXT:   omp.region {
+// CHECK-NEXT: %[[c:.*]] = "test.foo"() : () -> i1
+// CHECK-NEXT: cf.cond_br %[[c]], ^[[bb1:.*]](%[[c]] : i1), 
^[[bb2:.*]](%[[c]] : i1)
+// CHECK-NEXT:   ^[[bb1]](%[[arg:.*]]: i1):
+// CHECK-NEXT: "test.bar"() : () -> ()
+// CHECK-NEXT: omp.terminator
+// CHECK-NEXT:   ^[[bb2]](%[[arg2:.*]]: i1):
+// CHECK-NEXT: "test.baz"() : () -> ()
+// CHECK-NEXT: omp.terminator
+// CHECK-NEXT:   }
+// CHECK-NEXT:   omp.terminator
+// CHECK-NEXT: }
+// CHECK-NEXT: return
+func.func @omp_region_with_branch(%a: i32) {
+  omp.task {
+omp.region {
+  %c = "test.foo"() : () -> i1
+  cf.cond_br %c, ^bb1(%c: i1), ^bb2(%c: i1)
+^bb1(%arg: i1):
+  "test.bar"() : () ->

[Lldb-commits] [lldb] [mlir][OpenMP] Added `omp.structured_region` operation (PR #68825)

2023-10-11 Thread via lldb-commits 

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 OpenMP dialect.

---
Full diff: https://github.com/llvm/llvm-project/pull/68825.diff


4 Files Affected:

- (modified) mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td (+34) 
- (modified) mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp (+13) 
- (modified) mlir/test/Dialect/OpenMP/invalid.mlir (+22) 
- (added) mlir/test/Dialect/OpenMP/structured_region.mlir (+53) 


``diff
diff --git a/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td 
b/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
index 5da05476a683725..b9e041a22b5bffb 100644
--- a/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
+++ b/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
@@ -1987,4 +1987,38 @@ def ClauseRequiresAttr :
   EnumAttr {
 }
 
+
+def StructuredRegionOp : OpenMP_Op<"structured_region"> {
+  let summary = "Encapsulates a region in an OpenMP construct.";
+  let description = [{
+Encapsulates a region surrounded by an OpenMP Construct. The intended use
+of this operation is that within an OpenMP operation's region, there would
+be a single `omp.structured_region` operation and a terminator operation as
+shown below.
+
+```
+// Example with `omp.sections`
+omp.sections {
+  omp.structured_region {
+call @foo : () -> ()
+  }
+  omp.terminator
+}
+```
+
+This operation is especially more useful in operations that use `omp.yield`
+as a terminator. For example, in the proposed canonical loop operation,
+this operation would help fix the arguments of the yield operation and it
+is not affected by branches in the region assosciated with the canonical
+loop. In cases where the yielded value has to be a compile time constant,
+this provides a mechanism to avoid complex static analysis for the constant
+value.
+  }];
+  let regions = (region AnyRegion:$region);
+  let assemblyFormat = [{
+$region attr-dict
+  }];
+  let hasVerifier = 1;
+}
+
 #endif // OPENMP_OPS
diff --git a/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp 
b/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
index 2bf9355ed62676b..70811a230b36ccd 100644
--- a/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
+++ b/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
@@ -26,6 +26,7 @@
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/TypeSwitch.h"
 #include "llvm/Frontend/OpenMP/OMPConstants.h"
+#include "llvm/Support/Debug.h"
 #include 
 #include 
 
@@ -1468,6 +1469,18 @@ LogicalResult CancellationPointOp::verify() {
   return success();
 }
 
+//===--===//
+// RegionOp
+//===--===//
+
+LogicalResult StructuredRegionOp::verify() {
+  Operation *parentOp = (*this)->getParentOp();
+  assert(parentOp && "'omp.region' op must have a parent");
+  if (!isa(parentOp->getDialect()))
+return emitOpError() << "must be used under an OpenMP Dialect operation";
+  return success();
+}
+
 
//===--===//
 // DataBoundsOp
 
//===--===//
diff --git a/mlir/test/Dialect/OpenMP/invalid.mlir 
b/mlir/test/Dialect/OpenMP/invalid.mlir
index c8025249e27004e..94814a4d398b8c7 100644
--- a/mlir/test/Dialect/OpenMP/invalid.mlir
+++ b/mlir/test/Dialect/OpenMP/invalid.mlir
@@ -1657,3 +1657,25 @@ func.func @omp_target_exit_data(%map1: memref) {
 }
 
 llvm.mlir.global internal @_QFsubEx() : i32
+
+// -
+
+func.func @omp_region_invalid() {
+  // expected-error @below {{'omp.structured_region' op must be used under an 
OpenMP Dialect operation}}
+  omp.structured_region {
+omp.terminator
+  }
+  return
+}
+
+// -
+
+func.func @omp_region_invalid(%c: i1) {
+  scf.if %c {
+// expected-error @below {{'omp.structured_region' op must be used under 
an OpenMP Dialect operation}}
+omp.structured_region {
+  omp.terminator
+}
+  }
+  return
+}
diff --git a/mlir/test/Dialect/OpenMP/structured_region.mlir 
b/mlir/test/Dialect/OpenMP/structured_region.mlir
new file mode 100644
index 000..fc1e0edb07388eb
--- /dev/null
+++ b/mlir/test/Dialect/OpenMP/structured_region.mlir
@@ -0,0 +1,53 @@
+// RUN: mlir-opt %s | mlir-opt | FileCheck %s
+
+// CHECK-LABEL: @basic_omp_region
+// CHECK-NEXT: omp.parallel {
+// CHECK-NEXT:   omp.structured_region {
+// CHECK-NEXT: "test.foo"() : () -> ()
+// CHECK-NEXT: omp.terminator
+// CHECK-NEXT:   }
+// CHECK-NEXT:   omp.terminator
+// CHECK-NEXT: }
+// CHECK-NEXT: return
+func.func @basic_omp_region() {
+  omp.parallel {
+omp.structured_region {
+  "test.foo"() : () -> ()
+  omp.terminator
+}
+omp.termi

[Lldb-commits] [lldb] [mlir][OpenMP] Added `omp.structured_region` operation (PR #68825)

2023-10-11 Thread via lldb-commits 

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
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add SBType::FindNestedType() function (PR #68705)

2023-10-11 Thread via lldb-commits 

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 types and not ones deeper in the 
hierarchy.

https://github.com/llvm/llvm-project/pull/68705
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [mlir][OpenMP] Added `omp.structured_region` operation (PR #68825)

2023-10-11 Thread via lldb-commits 

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 omp.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 OpenMP dialect.
---
 mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td | 34 
 mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp  | 15 ++
 mlir/test/Dialect/OpenMP/region.mlir  | 53 +++
 3 files changed, 102 insertions(+)
 create mode 100644 mlir/test/Dialect/OpenMP/region.mlir

diff --git a/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td 
b/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
index b1e1fe00b8594a7..cf5b246178f5d7a 100644
--- a/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
+++ b/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
@@ -1787,4 +1787,38 @@ def ClauseRequiresAttr :
   EnumAttr {
 }
 
+
+def RegionOp : OpenMP_Op<"region"> {
+  let summary = "Encapsulates a region in an OpenMP construct.";
+  let description = [{
+Encapsulates a region surrounded by an OpenMP Construct. The intended use
+of this operation is that within an OpenMP operation's region, there would
+be a single `omp.region` operation and a terminator operation as shown
+below.
+
+```
+// Example with `omp.task`
+omp.task {
+  omp.region {
+call @foo : () -> ()
+  }
+  omp.terminator
+}
+```
+
+This operation is especially more useful in operations that use `omp.yield`
+as a terminator. For example, in the proposed canonical loop operation,
+this operation would help fix the arguments of the yield operation and it
+is not affected by branches in the region assosciated with the canonical
+loop. In cases where the yielded value has to be a compile time constant,
+this provides a mechanism to avoid complex static analysis for the constant
+value.
+  }];
+  let regions = (region AnyRegion:$block);
+  let assemblyFormat = [{
+$block attr-dict
+  }];
+  let hasVerifier = 1;
+}
+
 #endif // OPENMP_OPS
diff --git a/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp 
b/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
index 2ba5f1aca9cf6b2..2a2fcdb788cb99b 100644
--- a/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
+++ b/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
@@ -1524,6 +1524,21 @@ LogicalResult CancellationPointOp::verify() {
   return success();
 }
 
+//===--===//
+// RegionOp
+//===--===//
+
+LogicalResult RegionOp::verify() {
+  Operation *parentOp = (*this)->getParentOp();
+  if (!parentOp)
+return emitOpError() << "`omp.region` must have a parent";
+
+  if (!isa(parentOp->getDialect()))
+return emitOpError()
+   << "`omp.region` must be used under an OpenMP Dialect operation.";
+  return success();
+}
+
 #define GET_ATTRDEF_CLASSES
 #include "mlir/Dialect/OpenMP/OpenMPOpsAttributes.cpp.inc"
 
diff --git a/mlir/test/Dialect/OpenMP/region.mlir 
b/mlir/test/Dialect/OpenMP/region.mlir
new file mode 100644
index 000..4e0ddbc07e9ec9d
--- /dev/null
+++ b/mlir/test/Dialect/OpenMP/region.mlir
@@ -0,0 +1,53 @@
+// RUN: mlir-opt %s | mlir-opt | FileCheck %s
+
+// CHECK-LABEL: @basic_omp_region
+// CHECK-NEXT: omp.parallel {
+// CHECK-NEXT:   omp.region {
+// CHECK-NEXT: "test.foo"() : () -> ()
+// CHECK-NEXT: omp.terminator
+// CHECK-NEXT:   }
+// CHECK-NEXT:   omp.terminator
+// CHECK-NEXT: }
+// CHECK-NEXT: return
+func.func @basic_omp_region() {
+  omp.parallel {
+omp.region {
+  "test.foo"() : () -> ()
+  omp.terminator
+}
+omp.terminator
+  }
+  return
+}
+
+// CHECK-LABEL: @omp_region_with_branch
+// CHECK-NEXT: omp.task {
+// CHECK-NEXT:   omp.region {
+// CHECK-NEXT: %[[c:.*]] = "test.foo"() : () -> i1
+// CHECK-NEXT: cf.cond_br %[[c]], ^[[bb1:.*]](%[[c]] : i1), 
^[[bb2:.*]](%[[c]] : i1)
+// CHECK-NEXT:   ^[[bb1]](%[[arg:.*]]: i1):
+// CHECK-NEXT: "test.bar"() : () -> ()
+// CHECK-NEXT: omp.terminator
+// CHECK-NEXT:   ^[[bb2]](%[[arg2:.*]]: i1):
+// CHECK-NEXT: "test.baz"() : () -> ()
+// CHECK-NEXT: omp.terminator
+// CHECK-NEXT:   }
+// CHECK-NEXT:   omp.terminator
+// CHECK-NEXT: }
+// CHECK-NEXT: return
+func.func @omp_region_with_branch(%a: i32) {
+  omp.task {
+omp.region {
+  %c = "test.foo"() : () -> i1
+  cf.cond_br %c, ^bb1(%c: i1), ^bb2(%c: i1)
+^bb1(%arg: i1):
+  "test.bar"() : () -> ()
+  omp.terminator
+^bb2(%arg2: i1):
+  "test.baz"() : () -> ()
+  omp.terminator
+}
+omp.terminator
+  }
+  return
+}

>From f88bfd4cad856e915cb96b1238aac978f3aeb6d4 Mon Sep 17 00:00:00 2001
From: Shraiy

[Lldb-commits] [lldb] [lldb] Add SBType::FindNestedType() function (PR #68705)

2023-10-11 Thread Vlad Serebrennikov via lldb-commits 

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 clarify this.

https://github.com/llvm/llvm-project/pull/68705
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [OpenMP] Improve omp offload profiler (PR #68016)

2023-10-11 Thread via lldb-commits 

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 mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add SBType::FindNestedType() function (PR #68705)

2023-10-11 Thread via lldb-commits 

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 reviewers can clarify this.

It might be good to ask this as a separate question on the lldb project 
Discourse (https://discourse.llvm.org/c/subprojects/lldb/8).  That's likely to 
get more notice than a comment deep in a patch review.

https://github.com/llvm/llvm-project/pull/68705
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb-vscode] Update installation instructions (PR #68234)

2023-10-11 Thread Greg Clayton via lldb-commits 

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-commits

[Lldb-commits] [lldb] [LLDB][NFC] Create a namespace for the DWARF plugin (PR #68150)

2023-10-11 Thread Greg Clayton via lldb-commits 

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
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 098c927 - [lldb-vscode] Update installation instructions (#68234)

2023-10-11 Thread via lldb-commits 

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.diff

LOG: [lldb-vscode] Update installation instructions (#68234)

lldb-vscode had installation instructions based on creating a folder
inside ~/.vscode/extensions, which no longer works. A different
installation mechanism is needed based on a VSCode command. More can be
read in the contents of this patch.

Closes https://github.com/llvm/llvm-project/issues/63655

Added: 


Modified: 
lldb/tools/lldb-vscode/README.md

Removed: 




diff  --git a/lldb/tools/lldb-vscode/README.md 
b/lldb/tools/lldb-vscode/README.md
index 154ccefc5f59798..6f930293126d53e 100644
--- a/lldb/tools/lldb-vscode/README.md
+++ b/lldb/tools/lldb-vscode/README.md
@@ -1,18 +1,20 @@
 
 # Table of Contents
 
-- [Introduction](#Introduction)
-- [Installation](#Installation-Visual-Studio-Code)
+- [Table of Contents](#table-of-contents)
+- [Introduction](#introduction)
+- [Installation for Visual Studio Code](#installation-for-visual-studio-code)
 - [Configurations](#configurations)
-   - [Launch Configuration Settings](#launch-configuration-settings)
-   - [Attach Configuration Settings](#attach-configuration-settings)
-   - [Example configurations](#example-configurations)
-   - [Launching](#launching)
-   - [Attach to process using process ID](#attach-using-pid)
-   - [Attach to process by name](#attach-by-name)
-   - [Loading a core file](#loading-a-core-file)
-- [Custom Debugger Commands](#custom-debugger-commands)
-  - [startDebugging](#startDebugging)
+  - [Launch Configuration Settings](#launch-configuration-settings)
+  - [Attaching Settings](#attaching-settings)
+  - [Example configurations](#example-configurations)
+- [Launching](#launching)
+- [Attach using PID](#attach-using-pid)
+- [Attach by Name](#attach-by-name)
+- [Loading a Core File](#loading-a-core-file)
+- [Custom debugger commands](#custom-debugger-commands)
+  - [startDebugging](#startdebugging)
+  - [repl-mode](#repl-mode)
 
 # Introduction
 
@@ -24,52 +26,57 @@ get a full featured debugger with a well defined protocol.
 
 # Installation for Visual Studio Code
 
-Installing the plug-in involves creating a directory in the 
`~/.vscode/extensions` folder and copying the package.json file that is in the 
same directory as this
-documentation into it, and copying to symlinking a lldb-vscode binary into
-the `bin` directory inside the plug-in directory.
-
-If you want to make a stand alone plug-in that you can send to others on unix 
systems:
-
-```
-$ mkdir -p ~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0/bin
-$ cp package.json ~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0
-$ cd ~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0/bin
-$ cp /path/to/a/built/lldb-vscode .
-$ cp /path/to/a/built/liblldb.so .
+Installing the plug-in involves creating a directory in any location outside of
+`~/.vscode/extensions`. For example, `~/vscode-lldb` is a valid one. You'll 
also
+need a subfolder `bin`, e.g. `~/vscode-lldb/bin`. Then copy the `package.json`
+file that is in the same directory as this documentation into it, and symlink
+the `lldb-vscode` binary into the `bin` directory inside the plug-in directory.
+
+Finally, on VS Code, execute the command
+`Developer: Install Extension from Location` and pick the folder you just
+created, which would be `~/vscode-lldb` following the example above.
+
+If you want to make a stand alone plug-in that you can send to others on UNIX
+systems:
+
+```bash
+mkdir -p ~/llvm-org.lldb-vscode-0.1.0/bin
+cp package.json ~/llvm-org.lldb-vscode-0.1.0
+cd ~/llvm-org.lldb-vscode-0.1.0/bin
+cp /path/to/a/built/lldb-vscode .
+cp /path/to/a/built/liblldb.so .
 ```
 
-It is important to note that the directory `~/.vscode/extensions` works for 
users logged in locally to the machine. If you are remoting into the box using 
Visual Studio Code's Remote plugins (SSH, WSL, Docker) it will look for 
extensions on `~/.vscode-server/extensions` only and you will not see your just 
installed lldb-vscode plug-in. If you want this plugin to be visible to 
remoting users, you will need to either repeat the process above for the 
`~/.vscode-server` folder or create a symbolic link from it to 
`~/.vscode/extensions`:
+If you want to make a stand alone plug-in that you can send to others on macOS
+systems:
 
-```
-$ cd ~/.vscode-server/extensions
-$ ln -s ~/.vscode/extensions/llvm-org.lldb-vscode-0.1.0  
llvm-org.lldb-vscode-0.1.0
+```bash
+mkdir -p ~/llvm-org.lldb-vscode-0.1.0/bin
+cp package.json ~/llvm-org.lldb-vscode-0.1.0
+cd ~/llvm-org.lldb-vscode-0.1.0/bin
+cp /path/to/a/built/lldb-vscode .
+rsync -av /

[Lldb-commits] [lldb] [lldb-vscode] Update installation instructions (PR #68234)

2023-10-11 Thread Walter Erquinigo via lldb-commits 

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

[Lldb-commits] [lldb] [LLDB][NFC] Create a namespace for the DWARF plugin (PR #68150)

2023-10-11 Thread Walter Erquinigo via 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://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] add stop-at-user-entry option to process launch (PR #67019)

2023-10-11 Thread Greg Clayton via lldb-commits 

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
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB][NFC] Create a namespace for the DWARF plugin (PR #68150)

2023-10-11 Thread Walter Erquinigo via lldb-commits 

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

As a followup of https://github.com/llvm/llvm-project/pull/67851, I'm defining 
a new namespace `lldb_plugin::dwarf` for the classes in this 
Plugins/SymbolFile/DWARF folder. This change is very NFC and helped me with 
exporting the necessary symbols for my out-of-tree language plugin. The only 
two classes that I didn't change are DWARFDataExtractor, because that's being 
explicitly exported as part of lldb_private in `lldb-forward.h` , and the 
ClangDWARFASTParser, because that shouldn't be in the same namespace as the 
generic language-agnostic dwarf parser, but I'm okay with changing that. In any 
case, even if I didn't need this for my work, adding this namespace could be 
considered a good practice.
---
 .../include/lldb/Expression/DWARFExpression.h |  26 ++-
 .../lldb/Expression/DWARFExpressionList.h |  11 +-
 lldb/include/lldb/Symbol/TypeSystem.h |  10 +-
 lldb/source/Expression/DWARFExpression.cpp|   1 +
 .../SymbolFile/DWARF/AppleDWARFIndex.cpp  |   1 +
 .../SymbolFile/DWARF/AppleDWARFIndex.h|  37 ++--
 .../Plugins/SymbolFile/DWARF/DIERef.cpp   |   1 +
 lldb/source/Plugins/SymbolFile/DWARF/DIERef.h |   9 +-
 .../SymbolFile/DWARF/DWARFASTParser.cpp   |   1 +
 .../Plugins/SymbolFile/DWARF/DWARFASTParser.h |   7 +-
 .../SymbolFile/DWARF/DWARFASTParserClang.cpp  |   2 +
 .../SymbolFile/DWARF/DWARFASTParserClang.h| 160 ++
 .../SymbolFile/DWARF/DWARFAttribute.cpp   |   1 +
 .../Plugins/SymbolFile/DWARF/DWARFAttribute.h |   5 +
 .../Plugins/SymbolFile/DWARF/DWARFBaseDIE.cpp |   7 +-
 .../Plugins/SymbolFile/DWARF/DWARFBaseDIE.h   |   4 +
 .../SymbolFile/DWARF/DWARFCompileUnit.cpp |   1 +
 .../SymbolFile/DWARF/DWARFCompileUnit.h   |   6 +-
 .../Plugins/SymbolFile/DWARF/DWARFContext.cpp |   1 +
 .../Plugins/SymbolFile/DWARF/DWARFContext.h   |  50 +++---
 .../Plugins/SymbolFile/DWARF/DWARFDIE.cpp |   1 +
 .../Plugins/SymbolFile/DWARF/DWARFDIE.h   |   4 +
 .../SymbolFile/DWARF/DWARFDataExtractor.h |   2 +-
 .../SymbolFile/DWARF/DWARFDebugArangeSet.cpp  |   1 +
 .../SymbolFile/DWARF/DWARFDebugArangeSet.h|   4 +
 .../SymbolFile/DWARF/DWARFDebugAranges.cpp|   1 +
 .../SymbolFile/DWARF/DWARFDebugAranges.h  |   4 +
 .../SymbolFile/DWARF/DWARFDebugInfo.cpp   |   4 +-
 .../Plugins/SymbolFile/DWARF/DWARFDebugInfo.h |  14 +-
 .../SymbolFile/DWARF/DWARFDebugInfoEntry.cpp  |   1 +
 .../SymbolFile/DWARF/DWARFDebugInfoEntry.h|   4 +
 .../SymbolFile/DWARF/DWARFDebugMacro.cpp  |   1 +
 .../SymbolFile/DWARF/DWARFDebugMacro.h|   8 +-
 .../SymbolFile/DWARF/DWARFDebugRanges.cpp |   1 +
 .../SymbolFile/DWARF/DWARFDebugRanges.h   |   8 +-
 .../SymbolFile/DWARF/DWARFDeclContext.cpp |   1 +
 .../SymbolFile/DWARF/DWARFDeclContext.h   |   4 +
 .../Plugins/SymbolFile/DWARF/DWARFDefines.cpp |   6 +-
 .../Plugins/SymbolFile/DWARF/DWARFDefines.h   |   6 +-
 .../SymbolFile/DWARF/DWARFFormValue.cpp   |   1 +
 .../Plugins/SymbolFile/DWARF/DWARFFormValue.h |   6 +-
 .../Plugins/SymbolFile/DWARF/DWARFIndex.cpp   |   1 +
 .../Plugins/SymbolFile/DWARF/DWARFIndex.h |  45 ++---
 .../SymbolFile/DWARF/DWARFTypeUnit.cpp|   1 +
 .../Plugins/SymbolFile/DWARF/DWARFTypeUnit.h  |   6 +-
 .../Plugins/SymbolFile/DWARF/DWARFUnit.cpp|  28 +--
 .../Plugins/SymbolFile/DWARF/DWARFUnit.h  |  19 ++-
 .../SymbolFile/DWARF/DebugNamesDWARFIndex.cpp |   3 +-
 .../SymbolFile/DWARF/DebugNamesDWARFIndex.h   |  41 ++---
 .../SymbolFile/DWARF/ManualDWARFIndex.cpp |   1 +
 .../SymbolFile/DWARF/ManualDWARFIndex.h   |  39 +++--
 .../Plugins/SymbolFile/DWARF/NameToDIE.cpp|   1 +
 .../Plugins/SymbolFile/DWARF/NameToDIE.h  |   7 +-
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  |  10 +-
 .../SymbolFile/DWARF/SymbolFileDWARF.h|  23 ++-
 .../DWARF/SymbolFileDWARFDebugMap.cpp |   5 +
 .../DWARF/SymbolFileDWARFDebugMap.h   |  15 +-
 .../SymbolFile/DWARF/SymbolFileDWARFDwo.cpp   |   1 +
 .../SymbolFile/DWARF/SymbolFileDWARFDwo.h |  11 +-
 .../SymbolFile/DWARF/UniqueDWARFASTType.cpp   |   1 +
 .../SymbolFile/DWARF/UniqueDWARFASTType.h |   7 +-
 .../TypeSystem/Clang/TypeSystemClang.cpp  |   1 +
 .../TypeSystem/Clang/TypeSystemClang.h|   2 +-
 63 files changed, 440 insertions(+), 251 deletions(-)

diff --git a/lldb/include/lldb/Expression/DWARFExpression.h 
b/lldb/include/lldb/Expression/DWARFExpression.h
index 5e03f539a272cac..624c189223981fa 100644
--- a/lldb/include/lldb/Expression/DWARFExpression.h
+++ b/lldb/include/lldb/Expression/DWARFExpression.h
@@ -18,7 +18,11 @@
 #include "llvm/DebugInfo/DWARF/DWARFLocationExpression.h"
 #include 
 
+namespace lldb_plugin {
+namespace dwarf

[Lldb-commits] [lldb] [LLDB][NFC] Create a namespace for the DWARF plugin (PR #68150)

2023-10-11 Thread Walter Erquinigo via lldb-commits 

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

[Lldb-commits] [lldb] [LLDB][NFC] Create a namespace for the DWARF plugin (PR #68150)

2023-10-11 Thread Greg Clayton via 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

[Lldb-commits] [lldb] Add `target modules dump separate-debug-info` (PR #66035)

2023-10-11 Thread Tom Yang via 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_file = module->GetSymbolFile(true)) {

zhyty wrote:

That's not valid syntax, and I'm not sure how to use a single `if` statement to 
capture the meaning. I could write by declaring `symbol_file` outside of the 
`if` statement condition, but I think that's unnecessarily verbose. Besides, 10 
lines up we do the same thing.

https://github.com/llvm/llvm-project/pull/66035
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix `po` alias by printing fix-its to the console. (PR #68755)

2023-10-11 Thread Pete Lawrence via lldb-commits 

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` alias by printing fix-its to the console.

The `po` alias now matches the behavior of the `expression` command when
the it can apply a Fix-It to an expression.
Modifications

- Add has `m_fixed_expression` to the `CommandObjectDWIMPrint` class a
`protected` member that stores the post Fix-It expression, just like the
`CommandObjectExpression` class.
- Converted messages to present tense.
- Add test cases that confirms a Fix-It for a C++ expression for both
`po` and `expressions`

rdar://115317419
---
 .../Commands/CommandObjectDWIMPrint.cpp   | 15 ++-
 .../Commands/CommandObjectExpression.cpp  |  8 ++--
 .../commands/expression/fixits/TestFixIts.py  |  8 +++-
 .../API/lang/cpp/expression-fixit/Makefile|  3 ++
 .../TestCppExpressionFixIt.py | 26 +++
 .../API/lang/cpp/expression-fixit/main.cpp|  5 +++
 lldb/test/API/lang/cpp/fixits/Makefile|  3 ++
 .../test/API/lang/cpp/fixits/TestCppFixIts.py | 44 +++
 lldb/test/API/lang/cpp/fixits/main.cpp|  5 +++
 9 files changed, 109 insertions(+), 8 deletions(-)
 create mode 100644 lldb/test/API/lang/cpp/expression-fixit/Makefile
 create mode 100644 
lldb/test/API/lang/cpp/expression-fixit/TestCppExpressionFixIt.py
 create mode 100644 lldb/test/API/lang/cpp/expression-fixit/main.cpp
 create mode 100644 lldb/test/API/lang/cpp/fixits/Makefile
 create mode 100644 lldb/test/API/lang/cpp/fixits/TestCppFixIts.py
 create mode 100644 lldb/test/API/lang/cpp/fixits/main.cpp

diff --git a/lldb/source/Commands/CommandObjectDWIMPrint.cpp 
b/lldb/source/Commands/CommandObjectDWIMPrint.cpp
index 7b168eab9e02d44..bdc17c9cffc779a 100644
--- a/lldb/source/Commands/CommandObjectDWIMPrint.cpp
+++ b/lldb/source/Commands/CommandObjectDWIMPrint.cpp
@@ -172,8 +172,19 @@ bool CommandObjectDWIMPrint::DoExecute(StringRef command,
   {
 auto *exe_scope = m_exe_ctx.GetBestExecutionContextScope();
 ValueObjectSP valobj_sp;
-ExpressionResults expr_result =
-target.EvaluateExpression(expr, exe_scope, valobj_sp, eval_options);
+std::string fixed_expression;
+
+ExpressionResults expr_result = target.EvaluateExpression(
+expr, exe_scope, valobj_sp, eval_options, &fixed_expression);
+
+// Only mention Fix-Its if the expression evaluator applied them.
+// Compiler errors refer to the final expression after applying Fix-It(s).
+if (!fixed_expression.empty() && target.GetEnableNotifyAboutFixIts()) {
+  Stream &error_stream = result.GetErrorStream();
+  error_stream << "  Evaluated this expression after applying 
Fix-It(s):\n";
+  error_stream << "" << fixed_expression << "\n";
+}
+
 if (expr_result == eExpressionCompleted) {
   if (verbosity != eDWIMPrintVerbosityNone) {
 StringRef flags;
diff --git a/lldb/source/Commands/CommandObjectExpression.cpp 
b/lldb/source/Commands/CommandObjectExpression.cpp
index e7e6e3820b99133..2834be660abaf53 100644
--- a/lldb/source/Commands/CommandObjectExpression.cpp
+++ b/lldb/source/Commands/CommandObjectExpression.cpp
@@ -439,11 +439,11 @@ bool 
CommandObjectExpression::EvaluateExpression(llvm::StringRef expr,
   ExpressionResults success = target.EvaluateExpression(
   expr, frame, result_valobj_sp, eval_options, &m_fixed_expression);
 
-  // We only tell you about the FixIt if we applied it.  The compiler errors
-  // will suggest the FixIt if it parsed.
+  // Only mention Fix-Its if the expression evaluator applied them.
+  // Compiler errors refer to the final expression after applying Fix-It(s).
   if (!m_fixed_expression.empty() && target.GetEnableNotifyAboutFixIts()) {
-error_stream.Printf("  Fix-it applied, fixed expression was: \n%s\n",
-m_fixed_expression.c_str());
+error_stream << "  Evaluated this expression after applying Fix-It(s):\n";
+error_stream << "" << m_fixed_expression << "\n";
   }
 
   if (result_valobj_sp) {
diff --git a/lldb/test/API/commands/expression/fixits/TestFixIts.py 
b/lldb/test/API/commands/expression/fixits/TestFixIts.py
index 3bdeb84b4e79726..38b242838c828f1 100644
--- a/lldb/test/API/commands/expression/fixits/TestFixIts.py
+++ b/lldb/test/API/commands/expression/fixits/TestFixIts.py
@@ -22,7 +22,9 @@ def test_with_dummy_target(self):
 self.assertEqual(
 result, lldb.eReturnStatusSuccessFinishResult, ret_val.GetError()
 )
-self.assertIn("Fix-it applied", ret_val.GetError())
+self.assertIn(
+"Evaluated this expression after applying Fix-It(s):", 
ret_val.GetError()
+)
 
 def test_with_target(self):
 """Test calling expressions with errors that can be fixed by the

[Lldb-commits] [lldb] [lldb] Fix `po` alias by printing fix-its to the console. (PR #68755)

2023-10-11 Thread Pete Lawrence via lldb-commits 

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` alias by printing fix-its to the console.

The `po` alias now matches the behavior of the `expression` command when
the it can apply a Fix-It to an expression.
Modifications

- Add has `m_fixed_expression` to the `CommandObjectDWIMPrint` class a
`protected` member that stores the post Fix-It expression, just like the
`CommandObjectExpression` class.
- Converted messages to present tense.
- Add test cases that confirms a Fix-It for a C++ expression for both
`po` and `expressions`

rdar://115317419
---
 .../Commands/CommandObjectDWIMPrint.cpp   | 15 ++-
 .../Commands/CommandObjectExpression.cpp  |  8 ++--
 .../commands/expression/fixits/TestFixIts.py  |  8 +++-
 lldb/test/API/lang/cpp/fixits/Makefile|  3 ++
 .../test/API/lang/cpp/fixits/TestCppFixIts.py | 44 +++
 lldb/test/API/lang/cpp/fixits/main.cpp|  5 +++
 6 files changed, 75 insertions(+), 8 deletions(-)
 create mode 100644 lldb/test/API/lang/cpp/fixits/Makefile
 create mode 100644 lldb/test/API/lang/cpp/fixits/TestCppFixIts.py
 create mode 100644 lldb/test/API/lang/cpp/fixits/main.cpp

diff --git a/lldb/source/Commands/CommandObjectDWIMPrint.cpp 
b/lldb/source/Commands/CommandObjectDWIMPrint.cpp
index 7b168eab9e02d44..bdc17c9cffc779a 100644
--- a/lldb/source/Commands/CommandObjectDWIMPrint.cpp
+++ b/lldb/source/Commands/CommandObjectDWIMPrint.cpp
@@ -172,8 +172,19 @@ bool CommandObjectDWIMPrint::DoExecute(StringRef command,
   {
 auto *exe_scope = m_exe_ctx.GetBestExecutionContextScope();
 ValueObjectSP valobj_sp;
-ExpressionResults expr_result =
-target.EvaluateExpression(expr, exe_scope, valobj_sp, eval_options);
+std::string fixed_expression;
+
+ExpressionResults expr_result = target.EvaluateExpression(
+expr, exe_scope, valobj_sp, eval_options, &fixed_expression);
+
+// Only mention Fix-Its if the expression evaluator applied them.
+// Compiler errors refer to the final expression after applying Fix-It(s).
+if (!fixed_expression.empty() && target.GetEnableNotifyAboutFixIts()) {
+  Stream &error_stream = result.GetErrorStream();
+  error_stream << "  Evaluated this expression after applying 
Fix-It(s):\n";
+  error_stream << "" << fixed_expression << "\n";
+}
+
 if (expr_result == eExpressionCompleted) {
   if (verbosity != eDWIMPrintVerbosityNone) {
 StringRef flags;
diff --git a/lldb/source/Commands/CommandObjectExpression.cpp 
b/lldb/source/Commands/CommandObjectExpression.cpp
index e7e6e3820b99133..2834be660abaf53 100644
--- a/lldb/source/Commands/CommandObjectExpression.cpp
+++ b/lldb/source/Commands/CommandObjectExpression.cpp
@@ -439,11 +439,11 @@ bool 
CommandObjectExpression::EvaluateExpression(llvm::StringRef expr,
   ExpressionResults success = target.EvaluateExpression(
   expr, frame, result_valobj_sp, eval_options, &m_fixed_expression);
 
-  // We only tell you about the FixIt if we applied it.  The compiler errors
-  // will suggest the FixIt if it parsed.
+  // Only mention Fix-Its if the expression evaluator applied them.
+  // Compiler errors refer to the final expression after applying Fix-It(s).
   if (!m_fixed_expression.empty() && target.GetEnableNotifyAboutFixIts()) {
-error_stream.Printf("  Fix-it applied, fixed expression was: \n%s\n",
-m_fixed_expression.c_str());
+error_stream << "  Evaluated this expression after applying Fix-It(s):\n";
+error_stream << "" << m_fixed_expression << "\n";
   }
 
   if (result_valobj_sp) {
diff --git a/lldb/test/API/commands/expression/fixits/TestFixIts.py 
b/lldb/test/API/commands/expression/fixits/TestFixIts.py
index 3bdeb84b4e79726..38b242838c828f1 100644
--- a/lldb/test/API/commands/expression/fixits/TestFixIts.py
+++ b/lldb/test/API/commands/expression/fixits/TestFixIts.py
@@ -22,7 +22,9 @@ def test_with_dummy_target(self):
 self.assertEqual(
 result, lldb.eReturnStatusSuccessFinishResult, ret_val.GetError()
 )
-self.assertIn("Fix-it applied", ret_val.GetError())
+self.assertIn(
+"Evaluated this expression after applying Fix-It(s):", 
ret_val.GetError()
+)
 
 def test_with_target(self):
 """Test calling expressions with errors that can be fixed by the 
FixIts."""
@@ -99,7 +101,9 @@ def test_with_target_error_applies_fixit(self):
 )
 self.assertEqual(result, lldb.eReturnStatusFailed, ret_val.GetError())
 
-self.assertIn("Fix-it applied, fixed expression was:", 
ret_val.GetError())
+self.assertIn(
+"Evaluated this expression after applying Fix-It(s):", 
ret_val.GetError()
+)
 self.assertIn

[Lldb-commits] [lldb] [lldb] Fix `po` alias by printing fix-its to the console. (PR #68755)

2023-10-11 Thread Pete Lawrence via lldb-commits 

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, I put the 2 new tests into a single, new file, which makes the file naming 
a bit simpler and set up for future FixIt tests specific to C++.

https://github.com/llvm/llvm-project/pull/68755
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [LLDB][NFC] Create a namespace for the DWARF plugin (PR #68150)

2023-10-11 Thread Walter Erquinigo via lldb-commits 

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

[Lldb-commits] [lldb] [lldb] [mostly NFC] Large WP foundation: WatchpointResources (PR #68845)

2023-10-11 Thread Jason Molenda via 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 type, and a list of Watchpoints 
that are using this WatchpointResource.

This current patch doesn't add any of the features of WatchpointResources that 
make them interesting -- a user asking to watch a 24 byte object could watch 
this with three 8 byte WatchpointResources.  Or a Watchpoint on 1 byte at 
0x1002 and a second watchpoint on 1 byte at 0x1003, these must both be served 
by a single WatchpointResource on that doubleword at 0x1000 on a 64-bit target, 
if two hardware watchpoint registers were used to track these separately, one 
of them may not be hit.  Or if you have one Watchpoint on a variable with a 
condition set, and another Watchpoint on that same variable with a command 
defined or different condition, or ignorecount, both of those Watchpoints need 
to evaluate their criteria/commands when their WatchpointResource has been hit.

There's a bit of code movement to rearrange things in the direction I'll need 
for implementing this feature, so I want to start with reviewing & landing this 
mostly NFC patch and we can focus on the algorithmic choices about how 
WatchpointResources are shared and handled as they're triggeed, separately.

This patch also stops printing "Watchpoint  hit: old value: , new vlaue: 
" for Read watchpoints.  I could make an argument for print "Watchpoint  
hit: current value " but the current output doesn't make any sense, and the 
user can print the value if they are particularly interested.  Read watchpoints 
are used primarily to understand what code is reading a variable.

This patch adds more fallbacks for how to print the objects being watched if we 
have types, instead of assuming they are all integral values, so a struct will 
print its elements.  As large watchpoints are added, we'll be doing a lot more 
of those.

To track the WatchpointSP in the WatchpointResources, I changed the internal 
API which took a WatchpointSP and devolved it to a Watchpoint*, which meant 
touching several different Process files. I removed the watchpoint code in 
ProcessKDP which only reported that watchpoints aren't supported, the base 
class does that already.

I haven't yet changed how we receive a watchpoint to identify the 
WatchpointResource responsible for the trigger, and identify all Watchpoints 
that are using this Resource to evaluate their conditions etc.  This is the 
same work that a BreakpointSite needs to do when it has been tiggered, where 
multiple Breakpoints may be at the same address.

There is not yet any printing of the Resources that a Watchpoint is implemented 
in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).

"watchpoint set var" and "watchpoint set expression" take a size argument which 
was previously 1, 2, 4, or 8 (an enum).  I've changed this to an unsigned int.  
Most hardware implementations can only watch 1, 2, 4, 8 byte ranges, but with 
Resources we'll allow a user to ask for different sized watchpoints and set 
them in hardware-expressble terms soon.

I've annotated areas where I know there is work still needed with LWP_TODO that 
I'll be working on once this is landed.

I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.

https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116

>From 791fd06fe642f1163c39d79c57c7a6daae2c8ea6 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Wed, 11 Oct 2023 20:05:58 -0700
Subject: [PATCH] [lldb] [mostly NFC] Large WP foundation: WatchpointResources

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 type, and a list of Watchpoints that are using this
WatchpointResource.

This current patch doesn't add any of the features of WatchpointResources
that make them interesting -- a user asking to watch a 24 byte
object could watch this with three 8 byte WatchpointResources.  Or
a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte
at 0x1003, these must both be served by a single WatchpointResource
on that doubleword at 0x1000 on a 64-bit target, if two hardware
watchpoint registers were used to track these separately, one of
them may not be hit.  Or if you have one Watchpoint on a variable
with a condition set, and another Watchpoint on that same variable
with a command defined or different condition, or ignorecount, both
of those Watchpoints need to evaluate their criteria/commands when
their WatchpointResource has been hit.

There's a bit of code movement to rearrange things in the direction
I'll need for implementing this feature, so I want to start with
reviewing & landing this mostly NFC patch and we can f

[Lldb-commits] [lldb] [lldb] [mostly NFC] Large WP foundation: WatchpointResources (PR #68845)

2023-10-11 Thread via lldb-commits 

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, a type, and a list of Watchpoints 
that are using this WatchpointResource.

This current patch doesn't add any of the features of WatchpointResources that 
make them interesting -- a user asking to watch a 24 byte object could watch 
this with three 8 byte WatchpointResources.  Or a Watchpoint on 1 byte at 
0x1002 and a second watchpoint on 1 byte at 0x1003, these must both be served 
by a single WatchpointResource on that doubleword at 0x1000 on a 64-bit target, 
if two hardware watchpoint registers were used to track these separately, one 
of them may not be hit.  Or if you have one Watchpoint on a variable with a 
condition set, and another Watchpoint on that same variable with a command 
defined or different condition, or ignorecount, both of those Watchpoints need 
to evaluate their criteria/commands when their WatchpointResource has been hit.

There's a bit of code movement to rearrange things in the direction I'll need 
for implementing this feature, so I want to start with reviewing & landing 
this mostly NFC patch and we can focus on the algorithmic choices about how 
WatchpointResources are shared and handled as they're triggeed, separately.

This patch also stops printing "Watchpoint  hit: old value: , 
new vlaue: " for Read watchpoints.  I could make an argument for print 
"Watchpoint  hit: current value " but the current output 
doesn't make any sense, and the user can print the value if they are 
particularly interested.  Read watchpoints are used primarily to understand 
what code is reading a variable.

This patch adds more fallbacks for how to print the objects being watched if we 
have types, instead of assuming they are all integral values, so a struct will 
print its elements.  As large watchpoints are added, we'll be doing a lot more 
of those.

To track the WatchpointSP in the WatchpointResources, I changed the internal 
API which took a WatchpointSP and devolved it to a Watchpoint*, which meant 
touching several different Process files. I removed the watchpoint code in 
ProcessKDP which only reported that watchpoints aren't supported, the base 
class does that already.

I haven't yet changed how we receive a watchpoint to identify the 
WatchpointResource responsible for the trigger, and identify all Watchpoints 
that are using this Resource to evaluate their conditions etc.  This is the 
same work that a BreakpointSite needs to do when it has been tiggered, where 
multiple Breakpoints may be at the same address.

There is not yet any printing of the Resources that a Watchpoint is implemented 
in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).

"watchpoint set var" and "watchpoint set expression" take a size argument which 
was previously 1, 2, 4, or 8 (an enum).  I've changed this to an unsigned int.  
Most hardware implementations can only watch 1, 2, 4, 8 byte ranges, but with 
Resources we'll allow a user to ask for different sized watchpoints and set 
them in hardware-expressble terms soon.

I've annotated areas where I know there is work still needed with LWP_TODO that 
I'll be working on once this is landed.

I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.

https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116

---

Patch is 54.63 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/68845.diff


28 Files Affected:

- (modified) lldb/include/lldb/Breakpoint/Watchpoint.h (+1-1) 
- (modified) lldb/include/lldb/Interpreter/OptionGroupWatchpoint.h (+2-3) 
- (modified) lldb/include/lldb/Target/Process.h (+10-2) 
- (added) lldb/include/lldb/Target/WatchpointResource.h (+57) 
- (added) lldb/include/lldb/Target/WatchpointResourceList.h (+85) 
- (modified) lldb/include/lldb/lldb-forward.h (+2) 
- (modified) lldb/source/API/SBWatchpoint.cpp (+2-2) 
- (modified) lldb/source/Breakpoint/Watchpoint.cpp (+56-15) 
- (modified) lldb/source/Commands/CommandObjectWatchpoint.cpp (+4-4) 
- (modified) lldb/source/Interpreter/OptionGroupWatchpoint.cpp (+6-37) 
- (modified) lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp (-14) 
- (modified) lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.h (-7) 
- (modified) lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp (+9) 
- (modified) lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp 
(+21-19) 
- (modified) lldb/source/Plugins/Process/Windows/Common/ProcessWindows.h (+4-2) 
- (modified) lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
(+143-61) 
- (modified) lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h (+4-2) 
- (modified) lldb/source/Target/CMakeLists.txt (+2) 
- (modified) lldb/source/Target/Proces

[Lldb-commits] [lldb] [lldb] [mostly NFC] Large WP foundation: WatchpointResources (PR #68845)

2023-10-11 Thread via lldb-commits 

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 -- 
lldb/include/lldb/Target/WatchpointResource.h 
lldb/include/lldb/Target/WatchpointResourceList.h 
lldb/source/Target/WatchpointResource.cpp 
lldb/source/Target/WatchpointResourceList.cpp 
lldb/include/lldb/Breakpoint/Watchpoint.h 
lldb/include/lldb/Interpreter/OptionGroupWatchpoint.h 
lldb/include/lldb/Target/Process.h lldb/include/lldb/lldb-forward.h 
lldb/source/API/SBWatchpoint.cpp lldb/source/Breakpoint/Watchpoint.cpp 
lldb/source/Commands/CommandObjectWatchpoint.cpp 
lldb/source/Interpreter/OptionGroupWatchpoint.cpp 
lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp 
lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.h 
lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp 
lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp 
lldb/source/Plugins/Process/Windows/Common/ProcessWindows.h 
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h 
lldb/source/Target/Process.cpp lldb/source/Target/StopInfo.cpp 
lldb/source/Target/Target.cpp 
lldb/test/API/commands/watchpoints/watchpoint_count/main.c 
lldb/test/Shell/Watchpoint/Inputs/val.c
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Interpreter/OptionGroupWatchpoint.cpp 
b/lldb/source/Interpreter/OptionGroupWatchpoint.cpp
index d1ae916cd74b..48cbc9ec0e75 100644
--- a/lldb/source/Interpreter/OptionGroupWatchpoint.cpp
+++ b/lldb/source/Interpreter/OptionGroupWatchpoint.cpp
@@ -43,8 +43,15 @@ static constexpr OptionDefinition g_option_table[] = {
 {LLDB_OPT_SET_1, false, "watch", 'w', OptionParser::eRequiredArgument,
  nullptr, OptionEnumValues(g_watch_type), 0, eArgTypeWatchType,
  "Specify the type of watching to perform."},
-{LLDB_OPT_SET_1, false, "size", 's', OptionParser::eRequiredArgument,
- nullptr, {}, 0, eArgTypeByteSize, 
+{LLDB_OPT_SET_1,
+ false,
+ "size",
+ 's',
+ OptionParser::eRequiredArgument,
+ nullptr,
+ {},
+ 0,
+ eArgTypeByteSize,
  "Number of bytes to use to watch a region."},
 {LLDB_OPT_SET_2,
  false,

``




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