[Lldb-commits] [PATCH] D137583: [lldb] Fix simple template names and template params with scope qualifiers

2022-11-10 Thread Aaron Ballman via Phabricator via lldb-commits 
aaron.ballman added a comment.

In D137583#3917735 , @dblaikie wrote:

> In D137583#3917706 , @aaron.ballman 
> wrote:
>
>>> ...we expect template params to be fully qualified when comparing them for 
>>> simple template names
>>
>> So lldb is not inspecting the AST, they're doing reflection (of a sort) on 
>> the pretty printed names? Or am I misunderstanding something?
>
> Not reflection as such - but building names for the user, but partly from the 
> AST - basically LLDB wants to be able to produce the same name that 
> CGDebugInfo produces - so, maybe it should produce it the same way as 
> CGDebugInfo, which isn't to use the pretty printer from scratch.

Ah thank you for the clarification, that makes more sense to me.

> @aeubanks would this work for lldb's use case? 
> https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CGDebugInfo.cpp#L5229
>  it'd be identical to the original debug info generation, and looks like it 
> doesn't require a printing policy change/feature. Sorry I didn't think of 
> that earlier. I guess since `Qualified` would be `false` for lldb's use case, 
> you could go down into the implementation and just call the unqualified side 
> directly: `NamedDecl::printName(OS, Policy);` should print it unqualified for 
> this name, but respect the qualified printing policy flag for any nested 
> names, parameters, etc.

I agree that it seems pretty sensible for the debugger to use the same 
mechanisms as debug info in terms of what names to display for users.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137583/new/

https://reviews.llvm.org/D137583

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] e1b88c8 - [clang] Only use major version in resource dir

2022-11-10 Thread Timm Bäder via lldb-commits 

Author: Timm Bäder
Date: 2022-11-10T15:02:03+01:00
New Revision: e1b88c8a09be25b86b13f98755a9bd744b4dbf14

URL: 
https://github.com/llvm/llvm-project/commit/e1b88c8a09be25b86b13f98755a9bd744b4dbf14
DIFF: 
https://github.com/llvm/llvm-project/commit/e1b88c8a09be25b86b13f98755a9bd744b4dbf14.diff

LOG: [clang] Only use major version in resource dir

This causes unnecessary churn for downstreams.

For the full discussion, see 
https://discourse.llvm.org/t/should-we-continue-embed-the-full-llvm-version-in-lib-clang/62094

Differential Revision: https://reviews.llvm.org/D125860

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/Version.inc.in
clang/lib/Driver/Driver.cpp
clang/lib/Headers/CMakeLists.txt
clang/lib/Tooling/CMakeLists.txt
clang/runtime/CMakeLists.txt
compiler-rt/cmake/base-config-ix.cmake
lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
lldb/unittests/Expression/ClangParserTest.cpp
llvm/cmake/modules/LLVMExternalProjectUtils.cmake
polly/lib/External/isl/interface/extract_interface.cc

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index b0c01dd283e56..9ea3666b0ed72 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -176,6 +176,11 @@ code bases.
   g(42);
 }
 
+- Clang's resource dir used to include the full clang version. It will now
+  include only the major version. The new resource directory is
+  ``$prefix/lib/clang/$CLANG_MAJOR_VERSION`` and can be queried using
+  ``clang -print-resource-dir``, just like before.
+
 What's New in Clang |release|?
 ==
 Some of the major new features and improvements to Clang are listed

diff  --git a/clang/include/clang/Basic/Version.inc.in 
b/clang/include/clang/Basic/Version.inc.in
index fd80af4b51106..370da8506d142 100644
--- a/clang/include/clang/Basic/Version.inc.in
+++ b/clang/include/clang/Basic/Version.inc.in
@@ -1,5 +1,6 @@
 #define CLANG_VERSION @CLANG_VERSION@
 #define CLANG_VERSION_STRING "@CLANG_VERSION@"
 #define CLANG_VERSION_MAJOR @CLANG_VERSION_MAJOR@
+#define CLANG_VERSION_MAJOR_STRING "@CLANG_VERSION_MAJOR@"
 #define CLANG_VERSION_MINOR @CLANG_VERSION_MINOR@
 #define CLANG_VERSION_PATCHLEVEL @CLANG_VERSION_PATCHLEVEL@

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index a45c9e7f4957c..fd9d5c21e67c9 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -182,7 +182,7 @@ std::string Driver::GetResourcesPath(StringRef BinaryPath,
 // ../lib gets us to lib/ in both cases.
 P = llvm::sys::path::parent_path(Dir);
 llvm::sys::path::append(P, CLANG_INSTALL_LIBDIR_BASENAME, "clang",
-CLANG_VERSION_STRING);
+CLANG_VERSION_MAJOR_STRING);
   }
 
   return std::string(P.str());

diff  --git a/clang/lib/Headers/CMakeLists.txt 
b/clang/lib/Headers/CMakeLists.txt
index 874693c55af6f..b756dfed19abb 100644
--- a/clang/lib/Headers/CMakeLists.txt
+++ b/clang/lib/Headers/CMakeLists.txt
@@ -281,7 +281,7 @@ set(openmp_wrapper_files
   openmp_wrappers/new
 )
 
-set(output_dir ${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION}/include)
+set(output_dir 
${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION_MAJOR}/include)
 set(out_files)
 set(generated_files)
 
@@ -434,7 +434,7 @@ add_header_target("openmp-resource-headers" 
${openmp_wrapper_files})
 add_header_target("windows-resource-headers" ${windows_only_files})
 add_header_target("utility-resource-headers" ${utility_files})
 
-set(header_install_dir lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION}/include)
+set(header_install_dir 
lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION_MAJOR}/include)
 
 #
 # Install rules for the catch-all clang-resource-headers target

diff  --git a/clang/lib/Tooling/CMakeLists.txt 
b/clang/lib/Tooling/CMakeLists.txt
index 403d2dfb45e8e..595b3be585869 100644
--- a/clang/lib/Tooling/CMakeLists.txt
+++ b/clang/lib/Tooling/CMakeLists.txt
@@ -60,7 +60,7 @@ else()
   $
 # Skip this in debug mode because parsing AST.h is too slow
 --skip-processing=${skip_expensive_processing}
--I ${LLVM_BINARY_DIR}/lib/clang/${CLANG_VERSION}/include
+-I ${LLVM_BINARY_DIR}/lib/clang/${CLANG_VERSION_MAJOR}/include
 -I ${CLANG_SOURCE_DIR}/include
 -I ${LLVM_BINARY_DIR}/tools/clang/include
 -I ${LLVM_BINARY_DIR}/include

diff  --git a/clang/runtime/CMakeLists.txt b/clang/runtime/CMakeLists.txt
index 9f4633bc85b12..0cccf730e417d 100644
--- a/clang/runtime/CMakeLists.txt
+++ b/clang/runtime/CMakeLists.txt
@@ -82,9 +82,9 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND EXISTS 
${COMPILER_RT_SRC_ROOT}/)
-DCMAKE_CXX_COMPILER_LAUNCHER=${CMAKE_CXX_COMPILER_LAUNCHER}
-DLLVM_CONFIG_PATH=${LLVM_RUNTIME_

[Lldb-commits] [PATCH] D125860: [clang] Only use major version in resource dir

2022-11-10 Thread Timm Bäder via Phabricator via lldb-commits 
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe1b88c8a09be: [clang] Only use major version in resource dir 
(authored by tbaeder).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125860/new/

https://reviews.llvm.org/D125860

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/Version.inc.in
  clang/lib/Driver/Driver.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Tooling/CMakeLists.txt
  clang/runtime/CMakeLists.txt
  compiler-rt/cmake/base-config-ix.cmake
  lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
  lldb/unittests/Expression/ClangParserTest.cpp
  llvm/cmake/modules/LLVMExternalProjectUtils.cmake
  polly/lib/External/isl/interface/extract_interface.cc

Index: polly/lib/External/isl/interface/extract_interface.cc
===
--- polly/lib/External/isl/interface/extract_interface.cc
+++ polly/lib/External/isl/interface/extract_interface.cc
@@ -109,7 +109,7 @@
 	llvm::cl::value_desc("name"));
 
 static const char *ResourceDir =
-	CLANG_PREFIX "/lib/clang/" CLANG_VERSION_STRING;
+CLANG_PREFIX "/lib/clang/" CLANG_VERSION_MAJOR_STRING;
 
 /* Does decl have an attribute of the following form?
  *
Index: llvm/cmake/modules/LLVMExternalProjectUtils.cmake
===
--- llvm/cmake/modules/LLVMExternalProjectUtils.cmake
+++ llvm/cmake/modules/LLVMExternalProjectUtils.cmake
@@ -255,9 +255,9 @@
 set(llvm_config_path ${LLVM_CONFIG_PATH})
 
 if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
-  string(REGEX MATCH "[0-9]+\\.[0-9]+(\\.[0-9]+)?" CLANG_VERSION
+  string(REGEX MATCH "^[0-9]+" CLANG_VERSION_MAJOR
  ${PACKAGE_VERSION})
-  set(resource_dir "${LLVM_LIBRARY_DIR}/clang/${CLANG_VERSION}")
+  set(resource_dir "${LLVM_LIBRARY_DIR}/clang/${CLANG_VERSION_MAJOR}")
   set(flag_types ASM C CXX MODULE_LINKER SHARED_LINKER EXE_LINKER)
   foreach(type ${flag_types})
 set(${type}_flag -DCMAKE_${type}_FLAGS=-resource-dir=${resource_dir})
Index: lldb/unittests/Expression/ClangParserTest.cpp
===
--- lldb/unittests/Expression/ClangParserTest.cpp
+++ lldb/unittests/Expression/ClangParserTest.cpp
@@ -38,10 +38,11 @@
 #if !defined(_WIN32)
   std::string path_to_liblldb = "/foo/bar/lib/";
   std::string path_to_clang_dir =
-  "/foo/bar/" LLDB_INSTALL_LIBDIR_BASENAME "/clang/" CLANG_VERSION_STRING;
+  "/foo/bar/" LLDB_INSTALL_LIBDIR_BASENAME "/clang/" CLANG_VERSION_MAJOR_STRING;
 #else
   std::string path_to_liblldb = "C:\\foo\\bar\\lib";
-  std::string path_to_clang_dir = "C:\\foo\\bar\\lib\\clang\\" CLANG_VERSION_STRING;
+  std::string path_to_clang_dir =
+  "C:\\foo\\bar\\lib\\clang\\" CLANG_VERSION_MAJOR_STRING;
 #endif
   EXPECT_EQ(ComputeClangResourceDir(path_to_liblldb), path_to_clang_dir);
 
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangHost.cpp
@@ -55,7 +55,7 @@
   static const llvm::StringRef kResourceDirSuffixes[] = {
   // LLVM.org's build of LLDB uses the clang resource directory placed
   // in $install_dir/lib{,64}/clang/$clang_version.
-  CLANG_INSTALL_LIBDIR_BASENAME "/clang/" CLANG_VERSION_STRING,
+  CLANG_INSTALL_LIBDIR_BASENAME "/clang/" CLANG_VERSION_MAJOR_STRING,
   // swift-lldb uses the clang resource directory copied from swift, which
   // by default is placed in $install_dir/lib{,64}/lldb/clang. LLDB places
   // it there, so we use LLDB_INSTALL_LIBDIR_BASENAME.
Index: compiler-rt/cmake/base-config-ix.cmake
===
--- compiler-rt/cmake/base-config-ix.cmake
+++ compiler-rt/cmake/base-config-ix.cmake
@@ -38,14 +38,14 @@
 
 if (LLVM_TREE_AVAILABLE)
   # Compute the Clang version from the LLVM version.
-  # FIXME: We should be able to reuse CLANG_VERSION variable calculated
+  # FIXME: We should be able to reuse CLANG_VERSION_MAJOR variable calculated
   #in Clang cmake files, instead of copying the rules here.
-  string(REGEX MATCH "[0-9]+\\.[0-9]+(\\.[0-9]+)?" CLANG_VERSION
+  string(REGEX MATCH "^[0-9]+" CLANG_VERSION_MAJOR
  ${PACKAGE_VERSION})
   # Setup the paths where compiler-rt runtimes and headers should be stored.
-  set(COMPILER_RT_OUTPUT_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION})
+  set(COMPILER_RT_OUTPUT_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION_MAJOR})
   set(COMPILER_RT_EXEC_OUTPUT_DIR ${LLVM_RUNTIME_OUTPUT_INTDIR})
-  set(COMPILER_RT_INSTALL_PATH lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION})
+  set(COMPILER_RT_INSTALL_PATH lib${LLVM_LIBDIR_SUFFIX}/clang/${C

[Lldb-commits] [PATCH] D137000: [lldb] Make callback-based formatter matching available from the CLI.

2022-11-10 Thread Jorge Gorbe Moya via Phabricator via lldb-commits 
jgorbe added a comment.

In D137000#3915943 , @jingham wrote:

> It is a bit odd to follow the what the help summary says is a valid option 
> set and then get an error.   But this is a corner case, and since you say 
> explicitly that you can't provide both that's probably good enough.  Would 
> you mind changing "Incompatible with" to: "Cannot be specified at the same 
> time as".  Incompatible isn't precise - does it mean you can't use them both, 
> or that if you do something weird will happen?

After following Pavel's suggestion to remove the short flag it doesn't show up 
at all in the help summary, so the help summary still shows a valid option set. 
It just lists the long flag for the new option in the detailed list after the 
summary, like this:

  Command Options Usage:
type summary add -c [-Oprvx] [-C ] [-w ]  [ 
[...]]
type summary add [-ehprvx] -s  [-C ] [-w ] 
[-n ]  [ [...]]
type summary add [-Pehprvx] [-C ] [-w ] [-n ] [-F 
] [-o ]  [ [...]]
  
 --recognizer-function
  The names in the argument list are actually the names of python 
functions that decide whether to use this summary for any given type. Cannot be 
specified at the same time as --regex (-x).



> Other than that, this is fine.  Thanks for working on this.

Thank you both for helping me land this feature! :)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137000/new/

https://reviews.llvm.org/D137000

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D137000: [lldb] Make callback-based formatter matching available from the CLI.

2022-11-10 Thread Jorge Gorbe Moya via Phabricator via lldb-commits 
jgorbe updated this revision to Diff 474573.
jgorbe added a comment.

- Clarified help text for `--recognizer-function` as suggested by reviewer. 
Instead of "Incompatible with --regex (-x)." now it says "Cannot be specified 
at the same time as --regex (-x)."
- Rebased on top of current HEAD.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137000/new/

https://reviews.llvm.org/D137000

Files:
  lldb/docs/use/variable.rst
  lldb/examples/synthetic/recognizer_function/example.py
  lldb/examples/synthetic/recognizer_function/lldb-commands
  lldb/examples/synthetic/recognizer_function/program.cpp
  lldb/source/Commands/CommandObjectType.cpp
  lldb/source/Commands/Options.td
  
lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py
  
lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py

Index: lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py
===
--- lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py
+++ lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py
@@ -24,7 +24,7 @@
 return None
 
 
-def __lldb_init_module(debugger, dict):
+def register_formatters(debugger):
 cat = debugger.CreateCategory("callback_formatters")
 cat.AddTypeSummary(
 lldb.SBTypeNameSpecifier("formatters_with_callback.derives_from_base",
Index: lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py
===
--- lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py
+++ lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py
@@ -16,7 +16,7 @@
 # Find the line number to break at.
 self.line = line_number('main.cpp', '// Set break point at this line.')
 
-def test_callback_matchers(self):
+def test_callback_matchers_api_registration(self):
 """Test data formatter commands."""
 self.build()
 
@@ -31,6 +31,7 @@
 # now set up a summary function that uses a python callback to match
 # classes that derive from `Base`.
 self.runCmd("command script import --allow-reload ./formatters_with_callback.py")
+self.runCmd("script formatters_with_callback.register_formatters(lldb.debugger)")
 
 # Now `derived` should use our callback summary + synthetic children.
 self.expect("frame variable derived",
@@ -47,3 +48,40 @@
 substrs=['hello from callback summary'])
 self.expect("frame variable nd",
 substrs=['z = '])
+
+def test_callback_matchers_cli_registration(self):
+"""Test data formatter commands."""
+self.build()
+
+_, process, thread, _ = lldbutil.run_to_line_breakpoint(
+self, lldb.SBFileSpec("main.cpp"), self.line)
+
+# Print derived without a formatter.
+self.expect("frame variable derived",
+substrs=['x = ',
+ 'y = '])
+
+# now set up a summary function that uses a python callback to match
+# classes that derive from `Base`.
+self.runCmd("command script import --allow-reload ./formatters_with_callback.py")
+self.runCmd("type summary add -e -s 'hello from callback summary' "
+"--recognizer-function formatters_with_callback.derives_from_base")
+self.runCmd("type synth add -l formatters_with_callback.SynthProvider "
+"--recognizer-function formatters_with_callback.derives_from_base")
+
+# Now `derived` should use our callback summary + synthetic children.
+self.expect("frame variable derived",
+substrs=['hello from callback summary',
+ 'synthetic_child = '])
+
+# But not other classes.
+self.expect("frame variable base", matching=False,
+substrs=['hello from callback summary'])
+self.expect("frame variable base",
+substrs=['x = '])
+
+self.expect("frame variable nd", matching=False,
+substrs=['hello from callback summary'])
+self.expect("frame variable nd",
+substrs=['z = '])
+
Index: lldb/source/Commands/Options.td
===
--- lldb/source/Commands/Options.td
+++ lldb/source/Commands/Options.td
@@ -1189,6 +1189,11 @@
 Desc<"Don't use this format for references-to-type objects.">;
   def type_summary_add_regex : Option<"regex", "x">,
 Desc<"Type names are actually regular expressions.">;
+  def type_summary_add_recognizer_function :
+Option<"recognizer-function", "\\x01">,
+Des

[Lldb-commits] [lldb] 868186c - [lldb] Make callback-based formatter matching available from the CLI.

2022-11-10 Thread Jorge Gorbe Moya via lldb-commits 

Author: Jorge Gorbe Moya
Date: 2022-11-10T10:29:38-08:00
New Revision: 868186cf6cb7edba08c916f98f5f87a942bf50ba

URL: 
https://github.com/llvm/llvm-project/commit/868186cf6cb7edba08c916f98f5f87a942bf50ba
DIFF: 
https://github.com/llvm/llvm-project/commit/868186cf6cb7edba08c916f98f5f87a942bf50ba.diff

LOG: [lldb] Make callback-based formatter matching available from the CLI.

This change adds a `--recognizer-function` (`-R`) to `type summary add`
and `type synth add` that allows users to specify that the names in
the command are not type names but python function names.

It also adds an example to lldb/examples, and a section in the data
formatters documentation on how to use recognizer functions.

Differential Revision: https://reviews.llvm.org/D137000

Added: 
lldb/examples/synthetic/recognizer_function/example.py
lldb/examples/synthetic/recognizer_function/lldb-commands
lldb/examples/synthetic/recognizer_function/program.cpp

Modified: 
lldb/docs/use/variable.rst
lldb/source/Commands/CommandObjectType.cpp
lldb/source/Commands/Options.td

lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py

lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py

Removed: 




diff  --git a/lldb/docs/use/variable.rst b/lldb/docs/use/variable.rst
index e86b863f24856..1afe7c28b6b7e 100644
--- a/lldb/docs/use/variable.rst
+++ b/lldb/docs/use/variable.rst
@@ -1109,6 +1109,39 @@ only need to see the ones named B, H and Q, you can 
define a filter:
   (std::string) Q = "Hello world"
}
 
+Callback-based type matching
+
+
+Even though regular expression matching works well for the vast majority of 
data
+formatters (you normally know the name of the type you're writing a formatter
+for), there are some cases where it's useful to look at the type before 
deciding
+what formatter to apply.
+
+As an example scenario, imagine we have a code generator that produces some
+classes that inherit from a common ``GeneratedObject`` class, and we have a
+summary function and a synthetic child provider that work for all
+``GeneratedObject`` instances (they all follow the same pattern). However, 
there
+is no common pattern in the name of these classes, so we can't register the
+formatter neither by name nor by regular expression.
+
+In that case, you can write a recognizer function like this:
+
+::
+
+   def is_generated_object(sbtype, internal_dict):
+ for base in sbtype.get_bases_array():
+   if base.GetName() == "GeneratedObject"
+ return True
+ return False
+
+And pass this function to ``type summary add`` and ``type synthetic add`` using
+the flag ``--recognizer-function``.
+
+::
+
+   (lldb) type summary add --expand --python-function my_summary_function 
--recognizer-function is_generated_object
+   (lldb) type synthetic add --python-class my_child_provider 
--recognizer-function is_generated_object
+
 Objective-C Dynamic Type Discovery
 --
 

diff  --git a/lldb/examples/synthetic/recognizer_function/example.py 
b/lldb/examples/synthetic/recognizer_function/example.py
new file mode 100644
index 0..f2d4f75d50e8b
--- /dev/null
+++ b/lldb/examples/synthetic/recognizer_function/example.py
@@ -0,0 +1,63 @@
+# Formatters for classes that derive from Message.
+#
+# Usage:
+#   command script import ./example.py
+#   type summary add --expand --recognizer-function --python-function 
example.message_summary example.is_message_type
+#   type synth add --recognizer-function --python-class 
example.MessageChildProvider example.is_message_type
+
+import sys
+
+def is_message_type(t, internal_dict):
+  for base in t.get_bases_array():
+if base.GetName() == "Message":
+  return True
+  return False
+
+def message_summary(value, internal_dict):
+  # Could have used a summary string as well. All the work is done by the child
+  # provider.
+  return "Message"
+
+class MessageChildProvider:
+  def __init__(self, value, internal_dict):
+self.value = value
+self.synthetic_children = self._analyze_children(value)
+
+  def has_children(self):
+return self.num_children() > 0
+
+  def num_children(self):
+return len(self.synthetic_children)
+
+  def get_child_index(self, name):
+for index, child in enumerate(self.synthetic_children):
+  if child.GetName() == name:
+return index
+return None
+
+  def get_child_at_index(self, index):
+return self.synthetic_children[index]
+
+  def _rename_sbvalue(self, value):
+# We want to display the field with its original name without a trailing
+# underscore. So we create a new SBValue with the same type and address but
+# a 
diff erent name.
+name = value.GetName()
+assert name.endswith("_")
+new_name = name[:-1]
+return value.CreateValueFromAddress(new_

[Lldb-commits] [PATCH] D137000: [lldb] Make callback-based formatter matching available from the CLI.

2022-11-10 Thread Jorge Gorbe Moya via Phabricator via lldb-commits 
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG868186cf6cb7: [lldb] Make callback-based formatter matching 
available from the CLI. (authored by jgorbe).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137000/new/

https://reviews.llvm.org/D137000

Files:
  lldb/docs/use/variable.rst
  lldb/examples/synthetic/recognizer_function/example.py
  lldb/examples/synthetic/recognizer_function/lldb-commands
  lldb/examples/synthetic/recognizer_function/program.cpp
  lldb/source/Commands/CommandObjectType.cpp
  lldb/source/Commands/Options.td
  
lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py
  
lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py

Index: lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py
===
--- lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py
+++ lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py
@@ -24,7 +24,7 @@
 return None
 
 
-def __lldb_init_module(debugger, dict):
+def register_formatters(debugger):
 cat = debugger.CreateCategory("callback_formatters")
 cat.AddTypeSummary(
 lldb.SBTypeNameSpecifier("formatters_with_callback.derives_from_base",
Index: lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py
===
--- lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py
+++ lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py
@@ -16,7 +16,7 @@
 # Find the line number to break at.
 self.line = line_number('main.cpp', '// Set break point at this line.')
 
-def test_callback_matchers(self):
+def test_callback_matchers_api_registration(self):
 """Test data formatter commands."""
 self.build()
 
@@ -31,6 +31,7 @@
 # now set up a summary function that uses a python callback to match
 # classes that derive from `Base`.
 self.runCmd("command script import --allow-reload ./formatters_with_callback.py")
+self.runCmd("script formatters_with_callback.register_formatters(lldb.debugger)")
 
 # Now `derived` should use our callback summary + synthetic children.
 self.expect("frame variable derived",
@@ -47,3 +48,40 @@
 substrs=['hello from callback summary'])
 self.expect("frame variable nd",
 substrs=['z = '])
+
+def test_callback_matchers_cli_registration(self):
+"""Test data formatter commands."""
+self.build()
+
+_, process, thread, _ = lldbutil.run_to_line_breakpoint(
+self, lldb.SBFileSpec("main.cpp"), self.line)
+
+# Print derived without a formatter.
+self.expect("frame variable derived",
+substrs=['x = ',
+ 'y = '])
+
+# now set up a summary function that uses a python callback to match
+# classes that derive from `Base`.
+self.runCmd("command script import --allow-reload ./formatters_with_callback.py")
+self.runCmd("type summary add -e -s 'hello from callback summary' "
+"--recognizer-function formatters_with_callback.derives_from_base")
+self.runCmd("type synth add -l formatters_with_callback.SynthProvider "
+"--recognizer-function formatters_with_callback.derives_from_base")
+
+# Now `derived` should use our callback summary + synthetic children.
+self.expect("frame variable derived",
+substrs=['hello from callback summary',
+ 'synthetic_child = '])
+
+# But not other classes.
+self.expect("frame variable base", matching=False,
+substrs=['hello from callback summary'])
+self.expect("frame variable base",
+substrs=['x = '])
+
+self.expect("frame variable nd", matching=False,
+substrs=['hello from callback summary'])
+self.expect("frame variable nd",
+substrs=['z = '])
+
Index: lldb/source/Commands/Options.td
===
--- lldb/source/Commands/Options.td
+++ lldb/source/Commands/Options.td
@@ -1189,6 +1189,11 @@
 Desc<"Don't use this format for references-to-type objects.">;
   def type_summary_add_regex : Option<"regex", "x">,
 Desc<"Type names are actually regular expressions.">;
+  def type_summary_add_recognizer_function :
+Option<"recognizer-function", "\\x01">,
+Desc

[Lldb-commits] [PATCH] D137793: [lldb][test] TestConstStaticIntegralMember.py: fix for clang-{9, 11, 13}

2022-11-10 Thread Michael Buch via Phabricator via lldb-commits 
Michael137 created this revision.
Michael137 added a reviewer: aeubanks.
Herald added a subscriber: kristof.beyls.
Herald added a project: All.
Michael137 requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

**Summary**

The public lldb matrix bot is failing for tests compiled with clang-9, 
clang-11, clang-13.

This patch addresses these failures by evaluating the enum case that
doesn't cause malformed DWARF in older version of clang.

There was no particular reason we had to use `true` enum case
to reproduce the bug in #58383, so simply switch to use `false`
to get all bots passing again.

**Details**

In older versions of clang, the following snippet:

  enum EnumBool : bool {
enum_bool_case1 = false,
enum_bool_case2 = true,
  };
  
  struct A {
const static EnumBool enum_bool_val = enum_bool_case2;
  };

…results in following DWARF:

  0x0052:   DW_TAG_structure_type
  DW_AT_calling_convention(DW_CC_pass_by_value)
  DW_AT_name  ("A")
  DW_AT_byte_size (0x01)
  DW_AT_decl_file 
("/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/repro.cpp")
  DW_AT_decl_line (6)
  
  0x005b: DW_TAG_member
DW_AT_name("enum_bool_val")
DW_AT_type(0x0068 "const EnumBool")
DW_AT_decl_file   
("/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/repro.cpp")
DW_AT_decl_line   (7)
DW_AT_external(true)
DW_AT_declaration (true)
DW_AT_const_value (-1)

Note the `DW_AT_const_value == -1`

When evaluating `A::enum_bool_val` in the lldb we get:

  (lldb) p A::enum_bool_val
  error: expression failed to parse:
  error: Couldn't lookup symbols:
__ZN1A13enum_bool_valE

Enabling the DWARF logs we see:

  (arm64) clang-13.out: DWARFASTParserClang::ParseTypeFromDWARF (die = 
0x0068, decl_ctx = 0x136ac1e30 (die 0x000b)) DW_TAG_const_type name = 
'(null)')
  Failed to add const value to variable A::enum_bool_val: Can't store unsigned 
value 18446744073709551615 in integer with 1 bits.

This occurs because a boolean enum is considered an unsigned integer
type, but we try to initialize it with a `-1`.

**Testing**

- Confirmed locally that top-of-tree lldb correctly evaluates the previously 
failing expression when the test program is compiled with clang-13


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D137793

Files:
  
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
  lldb/test/API/lang/cpp/const_static_integral_member/main.cpp


Index: lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
===
--- lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
+++ lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
@@ -56,7 +56,7 @@
   const static auto wchar_min = std::numeric_limits::min();
 
   const static Enum enum_val = enum_case2;
-  const static EnumBool enum_bool_val = enum_bool_case2;
+  const static EnumBool enum_bool_val = enum_bool_case1;
   const static ScopedEnum scoped_enum_val = ScopedEnum::scoped_enum_case2;
   const static ScopedEnum not_enumerator_scoped_enum_val = 
static_cast(5);
   const static ScopedEnum not_enumerator_scoped_enum_val_2 =
Index: 
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
===
--- 
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
+++ 
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
@@ -58,7 +58,7 @@
 # Test an unscoped enum.
 self.expect_expr("A::enum_val", result_value="enum_case2")
 # Test an unscoped enum with bool as the underlying type.
-self.expect_expr("A::enum_bool_val", result_value="enum_bool_case2")
+self.expect_expr("A::enum_bool_val", result_value="enum_bool_case1")
 
 # Test a scoped enum.
 self.expect_expr("A::scoped_enum_val", 
result_value="scoped_enum_case2")


Index: lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
===
--- lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
+++ lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
@@ -56,7 +56,7 @@
   const static auto wchar_min = std::numeric_limits::min();
 
   const static Enum enum_val = enum_case2;
-  const static EnumBool enum_bool_val = enum_bool_case2;
+  const static EnumBool enum_bool_val = enum_bool_case1;
   const static ScopedEnum scoped_enum_val = ScopedEnum::scoped_enum_case2;
   const static ScopedEnum not_enumerator_scoped_enum_val =

[Lldb-commits] [PATCH] D137793: [lldb][test] TestConstStaticIntegralMember.py: fix for clang-{9, 11, 13}

2022-11-10 Thread Arthur Eubanks via Phabricator via lldb-commits 
aeubanks accepted this revision.
aeubanks added a comment.
This revision is now accepted and ready to land.

add a FIXME?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137793/new/

https://reviews.llvm.org/D137793

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D137793: [lldb][test] TestConstStaticIntegralMember.py: fix for clang-{9, 11, 13}

2022-11-10 Thread Michael Buch via Phabricator via lldb-commits 
Michael137 added a comment.

In D137793#3920209 , @aeubanks wrote:

> add a FIXME?

May be misunderstanding your suggestion, but the malformed DWARF got fixed 
somewhere between clang-14/clang-15. This is only an issue with older clang 
versions


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137793/new/

https://reviews.llvm.org/D137793

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D137793: [lldb][test] TestConstStaticIntegralMember.py: fix for clang-{9, 11, 13}

2022-11-10 Thread Arthur Eubanks via Phabricator via lldb-commits 
aeubanks added a comment.

In D137793#3920253 , @Michael137 
wrote:

> In D137793#3920209 , @aeubanks 
> wrote:
>
>> add a FIXME?
>
> May be misunderstanding your suggestion, but the malformed DWARF got fixed 
> somewhere between clang-14/clang-15. This is only an issue with older clang 
> versions. I'm merely getting the old buildbots to pass

I guess my question is should lldb support the malformed dwarf generated by 
older clangs?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137793/new/

https://reviews.llvm.org/D137793

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 9dcaca7 - [lldb][test] TestConstStaticIntegralMember.py: fix for clang-{9, 11, 13}

2022-11-10 Thread Michael Buch via lldb-commits 

Author: Michael Buch
Date: 2022-11-10T14:09:10-08:00
New Revision: 9dcaca706841fa38683eee341f24aafb58e6e3e9

URL: 
https://github.com/llvm/llvm-project/commit/9dcaca706841fa38683eee341f24aafb58e6e3e9
DIFF: 
https://github.com/llvm/llvm-project/commit/9dcaca706841fa38683eee341f24aafb58e6e3e9.diff

LOG: [lldb][test] TestConstStaticIntegralMember.py: fix for clang-{9,11,13}

**Summary**

The public lldb matrix bot is failing for tests compiled with clang-9, 
clang-11, clang-13.

This patch addresses these failures by evaluating the enum case that
doesn't cause malformed DWARF in older version of clang.

There was no particular reason we had to use `true` enum case
to reproduce the bug in #58383, so simply switch to use `false`
to get all bots passing again.

**Details**

In older versions of clang, the following snippet:
```
enum EnumBool : bool {
  enum_bool_case1 = false,
  enum_bool_case2 = true,
};

struct A {
  const static EnumBool enum_bool_val = enum_bool_case2;
};
```

…results in following DWARF:
```
0x0052:   DW_TAG_structure_type
DW_AT_calling_convention(DW_CC_pass_by_value)
DW_AT_name  ("A")
DW_AT_byte_size (0x01)
DW_AT_decl_file 
("/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/repro.cpp")
DW_AT_decl_line (6)

0x005b: DW_TAG_member
  DW_AT_name("enum_bool_val")
  DW_AT_type(0x0068 "const EnumBool")
  DW_AT_decl_file   
("/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/repro.cpp")
  DW_AT_decl_line   (7)
  DW_AT_external(true)
  DW_AT_declaration (true)
  DW_AT_const_value (-1)

```

Note the `DW_AT_const_value == -1`

When evaluating `A::enum_bool_val` in the lldb we get:
```
(lldb) p A::enum_bool_val
error: expression failed to parse:
error: Couldn't lookup symbols:
  __ZN1A13enum_bool_valE
```

Enabling the DWARF logs we see:

```
(arm64) clang-13.out: DWARFASTParserClang::ParseTypeFromDWARF (die = 
0x0068, decl_ctx = 0x136ac1e30 (die 0x000b)) DW_TAG_const_type name = 
'(null)')
Failed to add const value to variable A::enum_bool_val: Can't store unsigned 
value 18446744073709551615 in integer with 1 bits.
```

This occurs because a boolean enum is considered an unsigned integer
type, but we try to initialize it with a `-1`.

**Testing**

- Confirmed locally that top-of-tree lldb correctly
  evaluates the previously failing expression when
  the test program is compiled with clang-13

Differential Revision: https://reviews.llvm.org/D137793

Added: 


Modified: 

lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
lldb/test/API/lang/cpp/const_static_integral_member/main.cpp

Removed: 




diff  --git 
a/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
 
b/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
index 7fccbf8c43f5a..c490a073cfe8c 100644
--- 
a/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
+++ 
b/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
@@ -58,7 +58,7 @@ def test(self):
 # Test an unscoped enum.
 self.expect_expr("A::enum_val", result_value="enum_case2")
 # Test an unscoped enum with bool as the underlying type.
-self.expect_expr("A::enum_bool_val", result_value="enum_bool_case2")
+self.expect_expr("A::enum_bool_val", result_value="enum_bool_case1")
 
 # Test a scoped enum.
 self.expect_expr("A::scoped_enum_val", 
result_value="scoped_enum_case2")

diff  --git a/lldb/test/API/lang/cpp/const_static_integral_member/main.cpp 
b/lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
index 4128a4d050234..4275f471df6ae 100644
--- a/lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
+++ b/lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
@@ -56,7 +56,7 @@ struct A {
   const static auto wchar_min = std::numeric_limits::min();
 
   const static Enum enum_val = enum_case2;
-  const static EnumBool enum_bool_val = enum_bool_case2;
+  const static EnumBool enum_bool_val = enum_bool_case1;
   const static ScopedEnum scoped_enum_val = ScopedEnum::scoped_enum_case2;
   const static ScopedEnum not_enumerator_scoped_enum_val = 
static_cast(5);
   const static ScopedEnum not_enumerator_scoped_enum_val_2 =



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D137793: [lldb][test] TestConstStaticIntegralMember.py: fix for clang-{9, 11, 13}

2022-11-10 Thread Michael Buch via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9dcaca706841: [lldb][test] TestConstStaticIntegralMember.py: 
fix for clang-{9,11,13} (authored by Michael137).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137793/new/

https://reviews.llvm.org/D137793

Files:
  
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
  lldb/test/API/lang/cpp/const_static_integral_member/main.cpp


Index: lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
===
--- lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
+++ lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
@@ -56,7 +56,7 @@
   const static auto wchar_min = std::numeric_limits::min();
 
   const static Enum enum_val = enum_case2;
-  const static EnumBool enum_bool_val = enum_bool_case2;
+  const static EnumBool enum_bool_val = enum_bool_case1;
   const static ScopedEnum scoped_enum_val = ScopedEnum::scoped_enum_case2;
   const static ScopedEnum not_enumerator_scoped_enum_val = 
static_cast(5);
   const static ScopedEnum not_enumerator_scoped_enum_val_2 =
Index: 
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
===
--- 
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
+++ 
lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
@@ -58,7 +58,7 @@
 # Test an unscoped enum.
 self.expect_expr("A::enum_val", result_value="enum_case2")
 # Test an unscoped enum with bool as the underlying type.
-self.expect_expr("A::enum_bool_val", result_value="enum_bool_case2")
+self.expect_expr("A::enum_bool_val", result_value="enum_bool_case1")
 
 # Test a scoped enum.
 self.expect_expr("A::scoped_enum_val", 
result_value="scoped_enum_case2")


Index: lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
===
--- lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
+++ lldb/test/API/lang/cpp/const_static_integral_member/main.cpp
@@ -56,7 +56,7 @@
   const static auto wchar_min = std::numeric_limits::min();
 
   const static Enum enum_val = enum_case2;
-  const static EnumBool enum_bool_val = enum_bool_case2;
+  const static EnumBool enum_bool_val = enum_bool_case1;
   const static ScopedEnum scoped_enum_val = ScopedEnum::scoped_enum_case2;
   const static ScopedEnum not_enumerator_scoped_enum_val = static_cast(5);
   const static ScopedEnum not_enumerator_scoped_enum_val_2 =
Index: lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
===
--- lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
+++ lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
@@ -58,7 +58,7 @@
 # Test an unscoped enum.
 self.expect_expr("A::enum_val", result_value="enum_case2")
 # Test an unscoped enum with bool as the underlying type.
-self.expect_expr("A::enum_bool_val", result_value="enum_bool_case2")
+self.expect_expr("A::enum_bool_val", result_value="enum_bool_case1")
 
 # Test a scoped enum.
 self.expect_expr("A::scoped_enum_val", result_value="scoped_enum_case2")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D132624: [LLDB] Devirtualize coroutine promise types for `std::coroutine_handle`

2022-11-10 Thread Adrian Prantl via Phabricator via lldb-commits 
aprantl accepted this revision.
aprantl added a comment.
This revision is now accepted and ready to land.

Mechanically this looks good to me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132624/new/

https://reviews.llvm.org/D132624

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D137793: [lldb][test] TestConstStaticIntegralMember.py: fix for clang-{9, 11, 13}

2022-11-10 Thread Michael Buch via Phabricator via lldb-commits 
Michael137 added a comment.

In D137793#3920254 , @aeubanks wrote:

> In D137793#3920253 , @Michael137 
> wrote:
>
>> In D137793#3920209 , @aeubanks 
>> wrote:
>>
>>> add a FIXME?
>>
>> May be misunderstanding your suggestion, but the malformed DWARF got fixed 
>> somewhere between clang-14/clang-15. This is only an issue with older clang 
>> versions. I'm merely getting the old buildbots to pass
>
> I guess my question is should lldb support the malformed dwarf generated by 
> older clangs?

Ah I see, fair question. Presumably one of the reasons we don't bubble up the 
error from the `DWARFASTParserClang` to the expression evaluator is 
specifically because the DWARF can be malformed and evaluation may still 
succeed. In this case though I'm not sure we can do much because the generated 
DWARF breaks assumptions that LLDB (via Clang) makes about signedness. I'll 
double check the exact machinery though and report back


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137793/new/

https://reviews.llvm.org/D137793

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 353f265 - Apparently I moved the wrong one to "2", then Jason moved the right

2022-11-10 Thread Jim Ingham via lldb-commits 

Author: Jim Ingham
Date: 2022-11-10T15:23:51-08:00
New Revision: 353f265283e9ab209b544ab6818f3bd6ca071873

URL: 
https://github.com/llvm/llvm-project/commit/353f265283e9ab209b544ab6818f3bd6ca071873
DIFF: 
https://github.com/llvm/llvm-project/commit/353f265283e9ab209b544ab6818f3bd6ca071873.diff

LOG: Apparently I moved the wrong one to "2", then Jason moved the right
one, so this commit moves the wrong one back to no-"2"...

Added: 
lldb/test/API/lang/cpp/unique-types/TestUniqueTypes.py

Modified: 


Removed: 
lldb/test/API/lang/cpp/unique-types/TestUniqueTypes2.py



diff  --git a/lldb/test/API/lang/cpp/unique-types/TestUniqueTypes2.py 
b/lldb/test/API/lang/cpp/unique-types/TestUniqueTypes.py
similarity index 100%
rename from lldb/test/API/lang/cpp/unique-types/TestUniqueTypes2.py
rename to lldb/test/API/lang/cpp/unique-types/TestUniqueTypes.py



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D136844: [libclang] Expose completion result kind in `CXCompletionResult`

2022-11-10 Thread Alex Lorenz via Phabricator via lldb-commits 
arphaman accepted this revision.
arphaman added a comment.

LGTM!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136844/new/

https://reviews.llvm.org/D136844

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D137807: When scanning mach-o corefile, don't run all DynamicLoader plugins letting one of them Create when searching for binaries

2022-11-10 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda created this revision.
jasonmolenda added a reviewer: JDevlieghere.
jasonmolenda added a project: LLDB.
Herald added a project: All.
jasonmolenda requested review of this revision.
Herald added a subscriber: lldb-commits.

In  https://reviews.llvm.org/D133680 I changed a lot of how ProcessMachCore 
scans a corefile to figure out what kind of debug session this is (kernel, 
firmware, userland, etc) and where the binaries are.   
`ProcessMachCore::LoadBinariesViaMetadata()` calls 
`ObjectFile::LoadCoreFileImages()`, and under there, it is possible that the 
Process DynamicLoader will be set in the process of its scans.  Then back in 
`LoadBinariesViaMetadata()` it would check to see if the dynamic loader had 
been set.  It would do this by calling `ProcessMachCore::GetDynamicLoader()`, 
but this method, if `m_dyld_up` is empty, will call the plugin interface 
`FindPlugin` method with the minimal amount of information we have so far --- 
and pick the wrong dynamic loader plugin for a userland process.

This broke userland corefile loading in lldb; no the DynamicLoaderMacOSX plugin 
is not loaded, so we don't load any of the binaries in the corfile.  It's not a 
very commonly used type of corefile on Darwin systems, so it slipped by.  The 
corefiles created by lldb's `process save-core` include a lot of metadata which 
make this work correctly for them, so it didn't get caught by the testsuite.

The fix is to change the call to `GetDynamicLoader()` which can *set* the 
dynamic loader, and instead look at the ivar.  This is the only call to this 
method inside ProcessMachCore's methods.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D137807

Files:
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp


Index: lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
===
--- lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -327,9 +327,11 @@
   // corefile
   core_objfile->LoadCoreFileImages(*this);
 
-  // LoadCoreFileImges may have set the dynamic loader; if we now have
-  // a dynamic loader, save its name so we don't un-set it later.
-  if (GetDynamicLoader())
+  // LoadCoreFileImges may have set the dynamic loader, e.g. in
+  // PlatformDarwinKernel::LoadPlatformBinaryAndSetup().
+  // If we now have a dynamic loader, save its name so we don't 
+  // un-set it later.
+  if (m_dyld_up.get())
 m_dyld_plugin_name = GetDynamicLoader()->GetPluginName();
 }
 


Index: lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
===
--- lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -327,9 +327,11 @@
   // corefile
   core_objfile->LoadCoreFileImages(*this);
 
-  // LoadCoreFileImges may have set the dynamic loader; if we now have
-  // a dynamic loader, save its name so we don't un-set it later.
-  if (GetDynamicLoader())
+  // LoadCoreFileImges may have set the dynamic loader, e.g. in
+  // PlatformDarwinKernel::LoadPlatformBinaryAndSetup().
+  // If we now have a dynamic loader, save its name so we don't 
+  // un-set it later.
+  if (m_dyld_up.get())
 m_dyld_plugin_name = GetDynamicLoader()->GetPluginName();
 }
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D137807: When scanning mach-o corefile, don't run all DynamicLoader plugins letting one of them Create when searching for binaries

2022-11-10 Thread Jonas Devlieghere via Phabricator via lldb-commits 
JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

LGTM




Comment at: lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp:334
+  // un-set it later.
+  if (m_dyld_up.get())
 m_dyld_plugin_name = GetDynamicLoader()->GetPluginName();

```
if (m_dyld_up)
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137807/new/

https://reviews.llvm.org/D137807

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D137807: When scanning mach-o corefile, don't run all DynamicLoader plugins letting one of them Create when searching for binaries

2022-11-10 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda added a comment.

Thanks Jonas.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137807/new/

https://reviews.llvm.org/D137807

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D137807: When scanning mach-o corefile, don't run all DynamicLoader plugins letting one of them Create when searching for binaries

2022-11-10 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda updated this revision to Diff 474624.
jasonmolenda added a comment.

Jonas' feedback


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137807/new/

https://reviews.llvm.org/D137807

Files:
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp


Index: lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
===
--- lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -327,9 +327,11 @@
   // corefile
   core_objfile->LoadCoreFileImages(*this);
 
-  // LoadCoreFileImges may have set the dynamic loader; if we now have
-  // a dynamic loader, save its name so we don't un-set it later.
-  if (GetDynamicLoader())
+  // LoadCoreFileImges may have set the dynamic loader, e.g. in
+  // PlatformDarwinKernel::LoadPlatformBinaryAndSetup().
+  // If we now have a dynamic loader, save its name so we don't 
+  // un-set it later.
+  if (m_dyld_up)
 m_dyld_plugin_name = GetDynamicLoader()->GetPluginName();
 }
 


Index: lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
===
--- lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -327,9 +327,11 @@
   // corefile
   core_objfile->LoadCoreFileImages(*this);
 
-  // LoadCoreFileImges may have set the dynamic loader; if we now have
-  // a dynamic loader, save its name so we don't un-set it later.
-  if (GetDynamicLoader())
+  // LoadCoreFileImges may have set the dynamic loader, e.g. in
+  // PlatformDarwinKernel::LoadPlatformBinaryAndSetup().
+  // If we now have a dynamic loader, save its name so we don't 
+  // un-set it later.
+  if (m_dyld_up)
 m_dyld_plugin_name = GetDynamicLoader()->GetPluginName();
 }
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D137807: When scanning mach-o corefile, don't run all DynamicLoader plugins letting one of them Create when searching for binaries

2022-11-10 Thread Jason Molenda via Phabricator via lldb-commits 
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG48321eea9679: Check m_dyld_up directly in 
LoadBinariesViaMetadata (authored by jasonmolenda).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137807/new/

https://reviews.llvm.org/D137807

Files:
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp


Index: lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
===
--- lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -327,9 +327,11 @@
   // corefile
   core_objfile->LoadCoreFileImages(*this);
 
-  // LoadCoreFileImges may have set the dynamic loader; if we now have
-  // a dynamic loader, save its name so we don't un-set it later.
-  if (GetDynamicLoader())
+  // LoadCoreFileImges may have set the dynamic loader, e.g. in
+  // PlatformDarwinKernel::LoadPlatformBinaryAndSetup().
+  // If we now have a dynamic loader, save its name so we don't 
+  // un-set it later.
+  if (m_dyld_up)
 m_dyld_plugin_name = GetDynamicLoader()->GetPluginName();
 }
 


Index: lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
===
--- lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -327,9 +327,11 @@
   // corefile
   core_objfile->LoadCoreFileImages(*this);
 
-  // LoadCoreFileImges may have set the dynamic loader; if we now have
-  // a dynamic loader, save its name so we don't un-set it later.
-  if (GetDynamicLoader())
+  // LoadCoreFileImges may have set the dynamic loader, e.g. in
+  // PlatformDarwinKernel::LoadPlatformBinaryAndSetup().
+  // If we now have a dynamic loader, save its name so we don't 
+  // un-set it later.
+  if (m_dyld_up)
 m_dyld_plugin_name = GetDynamicLoader()->GetPluginName();
 }
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 48321ee - Check m_dyld_up directly in LoadBinariesViaMetadata

2022-11-10 Thread Jason Molenda via lldb-commits 

Author: Jason Molenda
Date: 2022-11-10T15:49:23-08:00
New Revision: 48321eea9679e1d8c5a30f4027e1aa49738aebf3

URL: 
https://github.com/llvm/llvm-project/commit/48321eea9679e1d8c5a30f4027e1aa49738aebf3
DIFF: 
https://github.com/llvm/llvm-project/commit/48321eea9679e1d8c5a30f4027e1aa49738aebf3.diff

LOG: Check m_dyld_up directly in LoadBinariesViaMetadata

In the restructuring I did in https://reviews.llvm.org/D133680 , I
call ObjectFile::LoadBinariesViaMetadata, and the process m_dyld
may be set by a method under there -- in
ProcessMachCore::LoadBinariesViaMetadata I wanted to check to see
if m_dyld_up had been set.  I did this by calling the GetDynamicLoader()
method, but that method will call FindPlugin() if there is no
dynamic loader yet, and the static dynamic loader plugin was being
loaded, preventing the scan for userland binaries in a userland
corefile.

Differential Revision: https://reviews.llvm.org/D137807
rdar://102210820

Added: 


Modified: 
lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp 
b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
index 37137b34f0484..593dc8535e641 100644
--- a/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
+++ b/lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
@@ -327,9 +327,11 @@ void ProcessMachCore::LoadBinariesViaMetadata() {
   // corefile
   core_objfile->LoadCoreFileImages(*this);
 
-  // LoadCoreFileImges may have set the dynamic loader; if we now have
-  // a dynamic loader, save its name so we don't un-set it later.
-  if (GetDynamicLoader())
+  // LoadCoreFileImges may have set the dynamic loader, e.g. in
+  // PlatformDarwinKernel::LoadPlatformBinaryAndSetup().
+  // If we now have a dynamic loader, save its name so we don't 
+  // un-set it later.
+  if (m_dyld_up)
 m_dyld_plugin_name = GetDynamicLoader()->GetPluginName();
 }
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D136844: [libclang] Expose completion result kind in `CXCompletionResult`

2022-11-10 Thread Egor Zhdan via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG97105e5bf70f: [libclang] Expose completion result kind in 
`CXCompletionResult` (authored by egorzhdan).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136844/new/

https://reviews.llvm.org/D136844

Files:
  clang/include/clang-c/Index.h
  clang/test/Index/arc-complete.m
  clang/test/Index/code-completion.cpp
  clang/test/Index/complete-at-directives.m
  clang/test/Index/complete-at-exprstmt.m
  clang/test/Index/complete-declarators.cpp
  clang/test/Index/complete-declarators.m
  clang/test/Index/complete-exprs.c
  clang/test/Index/complete-exprs.cpp
  clang/test/Index/complete-exprs.m
  clang/test/Index/complete-lambdas.cpp
  clang/test/Index/complete-lambdas.mm
  clang/test/Index/complete-memfunc-cvquals.cpp
  clang/test/Index/complete-method-decls.m
  clang/test/Index/complete-modules.m
  clang/test/Index/complete-preprocessor.m
  clang/test/Index/complete-recovery.m
  clang/test/Index/complete-stmt.c
  clang/test/Index/complete-super.cpp
  clang/test/Index/complete-synthesized.m
  clang/test/Index/complete-type-factors.m
  clang/tools/c-index-test/c-index-test.c
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/CIndexCodeCompletion.cpp
  clang/tools/libclang/libclang.map

Index: clang/tools/libclang/libclang.map
===
--- clang/tools/libclang/libclang.map
+++ clang/tools/libclang/libclang.map
@@ -4,6 +4,11 @@
 # On platforms where versions scripts are not used, this file will be used to
 # generate a list of exports for libclang.so
 
+LLVM_15 {
+  global:
+clang_getCompletionResultKindSpelling;
+};
+
 LLVM_13 {
   global:
 clang_BlockCommandComment_getArgText;
Index: clang/tools/libclang/CIndexCodeCompletion.cpp
===
--- clang/tools/libclang/CIndexCodeCompletion.cpp
+++ clang/tools/libclang/CIndexCodeCompletion.cpp
@@ -586,6 +586,20 @@
   includeBriefComments());
 
 CXCompletionResult R;
+switch (Results[I].Kind) {
+case CodeCompletionResult::RK_Declaration:
+  R.ResultKind = CXCompletionResult_Declaration;
+  break;
+case CodeCompletionResult::RK_Keyword:
+  R.ResultKind = CXCompletionResult_Keyword;
+  break;
+case CodeCompletionResult::RK_Macro:
+  R.ResultKind = CXCompletionResult_Macro;
+  break;
+case CodeCompletionResult::RK_Pattern:
+  R.ResultKind = CXCompletionResult_Pattern;
+  break;
+}
 R.CursorKind = Results[I].CursorKind;
 R.CompletionString = StoredCompletion;
 StoredResults.push_back(R);
@@ -666,6 +680,7 @@
 includeBriefComments(), Braced);
 
 CXCompletionResult R;
+R.ResultKind = CXCompletionResult_Declaration;
 R.CursorKind = CXCursor_OverloadCandidate;
 R.CompletionString = StoredCompletion;
 StoredResults.push_back(R);
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -5403,6 +5403,22 @@
   return clang_getCursorSpelling(C);
 }
 
+CXString
+clang_getCompletionResultKindSpelling(enum CXCompletionResultKind Kind) {
+  switch (Kind) {
+  case CXCompletionResult_Declaration:
+return cxstring::createRef("Declaration");
+  case CXCompletionResult_Keyword:
+return cxstring::createRef("Keyword");
+  case CXCompletionResult_Macro:
+return cxstring::createRef("Macro");
+  case CXCompletionResult_Pattern:
+return cxstring::createRef("Pattern");
+  }
+
+  llvm_unreachable("Unhandled CXCompletionResultKind");
+}
+
 CXString clang_getCursorKindSpelling(enum CXCursorKind Kind) {
   switch (Kind) {
   case CXCursor_FunctionDecl:
Index: clang/tools/c-index-test/c-index-test.c
===
--- clang/tools/c-index-test/c-index-test.c
+++ clang/tools/c-index-test/c-index-test.c
@@ -2512,7 +2512,10 @@
 unsigned index,
 FILE *file) {
   CXCompletionResult *completion_result = completion_results->Results + index;
-  CXString ks = clang_getCursorKindSpelling(completion_result->CursorKind);
+  CXString ks =
+  completion_result->CursorKind == CXCursor_NotImplemented
+  ? clang_getCompletionResultKindSpelling(completion_result->ResultKind)
+  : clang_getCursorKindSpelling(completion_result->CursorKind);
   unsigned annotationCount;
   enum CXCursorKind ParentKind;
   CXString ParentName;
Index: clang/test/Index/complete-type-factors.m
===
--- clang/test/Index/complete-type-factors.m
+++ clang/test/

[Lldb-commits] [lldb] 2082188 - [lldb/test] Fix app_specific_backtrace_crashlog.test (NFC)

2022-11-10 Thread Med Ismail Bennani via lldb-commits 

Author: Med Ismail Bennani
Date: 2022-11-10T18:32:18-08:00
New Revision: 2082188406965fe35ef3d8b1f2057ab7f8e15a43

URL: 
https://github.com/llvm/llvm-project/commit/2082188406965fe35ef3d8b1f2057ab7f8e15a43
DIFF: 
https://github.com/llvm/llvm-project/commit/2082188406965fe35ef3d8b1f2057ab7f8e15a43.diff

LOG: [lldb/test] Fix app_specific_backtrace_crashlog.test (NFC)

This patch fixes app_specific_backtrace_crashlog.test.

It was failing because one of the loaded images was built with
optimization which added a new warning message between the first
`CHECK` and the `CHECK-NEXT`, breaking the expected ordering.

Signed-off-by: Med Ismail Bennani 

Added: 


Modified: 

lldb/test/Shell/ScriptInterpreter/Python/Crashlog/app_specific_backtrace_crashlog.test

Removed: 




diff  --git 
a/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/app_specific_backtrace_crashlog.test
 
b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/app_specific_backtrace_crashlog.test
index 266b1b4ee404d..5ca5c51a3125c 100644
--- 
a/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/app_specific_backtrace_crashlog.test
+++ 
b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/app_specific_backtrace_crashlog.test
@@ -20,7 +20,7 @@
 
 
 # CHECK: (lldb) thread backtrace --extended true
-# CHECK-NEXT: * thread #1, queue = 'com.apple.main-thread', stop reason = 
EXC_CRASH (code=0, subcode=0x0)
+# CHECK: * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_CRASH 
(code=0, subcode=0x0)
 # CHECK-NEXT:   * frame #0: 0x0001a08c7224{{.*}}[artificial]
 # CHECK-NEXT: frame #1: 0x0001a08fdceb{{.*}}[artificial]
 # CHECK-NEXT: frame #2: 0x0001a08372c7{{.*}}[artificial]



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits