[Lldb-commits] [llvm] [lldb] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

2023-12-11 Thread Michał Górny via lldb-commits

mgorny wrote:

"Dylib" is LLVM-speech for `libLLVM.so` ("shared libraries" refer to individual 
split libraries, while "dylib" refers to the monolith), as in 
`-DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON`. And yes, that + 
standalone build with full *source* repository but linking against LLVM+Clang 
installed with `install-distribution` target.

And yeah, if you make a patch to add LLVMDebuginfod to libLLVM, I can test that 
here.

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits

Michael137 wrote:

> > > > Sorry, it's been a while since I last reviewed this and I must admit I 
> > > > forgot about this in the mean time. The only thing I'd like to check 
> > > > before we can land this is to hear from @Michael137 who has been 
> > > > actively working on FindTypes performance recently whether this aligns 
> > > > or clashes with what he's been working on so we don't get a mid-air 
> > > > collision between patches.
> > > 
> > > 
> > > Sounds good, I look forward to hearing if this fixes the issues as well. 
> > > Before this fix I ran a case where I did an expression like 
> > > "MyClass::iterator" and before this fix, with linux and no accelerator 
> > > tables, we would convert DWARF into clang AST types for over 2 million 
> > > types, and after this fix it went down to 11. This was when debugging 
> > > LLDB + LLVM + clang with debug info, so there were TONS of "iterator" 
> > > entries in the manual DWARF index.
> > > On Apple the type accelerator tables have the hash of the fully qualified 
> > > name which can help reduce the number of types we parse, but we don't 
> > > have this on linux even with DWARF5 + .debug_names
> > 
> > 
> > To add more context to @adrian-prantl's comment, we've been working on 
> > reviving https://reviews.llvm.org/D101950, which changes the way we 
> > complete record types. The main blocker was performance, because as you 
> > mention, we often end up doing these expensive namespace searches, which 
> > gets much more noticeable with D101950. The problem we saw was mostly 
> > triggered by the second lookup that `-gsimple-template-names` does in 
> > `FindTypes`.
> > I applied your patch on top of D101950 and performance seems to be much 
> > better (by 2 orders of magnitude). It did break some tests locally for me, 
> > so I'm just skimming this patch to see what changed
> 
> All tests passed on my machine from with this, so you might try those tests 
> without D101950 and see how things go? Happy to help if you need info on how 
> to do things with the new lookups.

All tests are passing for me now, it had to do with some badly resolved merge 
conflicts

> Do we need to fix this in the commit message when I squash? Or do I just 
> update the title of this PR?

I think when you press the `Squash and merge` button it will give you the 
chance to correct the title of the commit

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


[Lldb-commits] [lldb] [lldb-dap] Emit declarations along with variables (PR #74865)

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


@@ -1101,6 +1101,29 @@ std::string 
CreateUniqueVariableNameForDisplay(lldb::SBValue v,
 //   can use this optional information to present the
 //   children in a paged UI and fetch them in chunks."
 // }
+// "declaration": {
+//   "type": "object | undefined",
+//   "description": "Extension to the protocol that indicates the source
+//   location where the variable was declared. This value
+//   might not be present if no declaration is available.",
+//   "properties": {
+// "path": {
+//   "type": "string | undefined",
+//   "description": "The source file path where the variable was
+//   declared."
+// },
+// "line": {
+//   "type": "number | undefined",
+//   "description": "The 1-indexed source line where the variable was
+//  declared."
+// },
+// "column": {
+//   "type": "number | undefined",
+//   "description": "The 1-indexed source column where the variable was
+//  declared."
+// }
+//   }
+// }

clayborg wrote:

Can we document that is is an extension if it actually isn't part of the DAP 
protocol from the Microsoft website?

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


[Lldb-commits] [lldb] [lldb-dap] Emit declarations along with variables (PR #74865)

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

https://github.com/clayborg commented:

I am ok with this patch. I would just like to document what key/value pairs are 
extensions because the spec description in the comment was directly from the 
DAP Protocol website and it would be nice to let people know what are 
extensions.

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


[Lldb-commits] [lldb] [lldb-dap] Implement command directives (PR #74808)

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

clayborg wrote:

> > "error: one of your required 'attachCommands' failed, check the debug 
> > console for details"
> 
> This is a key thing that I didn't consider in the beginning. I'm going to 
> update this patch to only support `?`, and then I'll make another one for 
> `!`, because I need to explore how to send visible notifications to the IDE.

I will happily ok this if we can just return a pertinent error for at least 
`attach` and `launch`. We run these from both `attach` and `launch`:
- `initCommands`
- `preRunCommands`
- `attachCommands` or `launchCommands`
- `postRunCommands`

Outside of this we have `exitCommands` and `terminateCommands` which happend 
outside of this and we could either outlaw the use of `!` commands here (since 
the session will shut down soon anyway, so better to let it shutdown correctly. 
Then we have `stopCommands`. So my suggestion would be:
- Lets return an error with an error message of "failed to run 'XXXCommands', 
see debug console for details for launch and attach
- Outlaw `!` commands for any places that don't have a command where we can 
return an error. This would be easy to document in the package.json. 

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


[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

2023-12-11 Thread Kevin Frei via lldb-commits

kevinfrei wrote:

Is there some documentation that both me & google are missing somewhere? I'm 
trying to read between the lines of the scenario that's broken, with nothing 
but a log (that refers to a bunch of pretty important configuration files from 
somewhere I can't find) with a repo configuration that, again, I can't figure 
out. You say that we can't "build against LLMV as a dylib". Is this trying to 
build LLDB stand-alone, without a full LLVM repo around it? I'm also assuming 
you're actually talking about an SO and not a dylib, since the build is on 
Linux, not macOS. I really want to help, but I'm recently new to this space, so 
I'm missing a bunch of tribal knowledge.

Alternatively, if you have a repro, and can fix it by adding LLVMDebuginfod to 
libLLVM, that seems reasonable to me, given the design of LLVMDebuginfod 
(small, falls back to no functionality without libcurl, etc...) I've burned all 
day today trying to get a build & repro going, and have failed (my build is 
quite complicated). I'll try this on a personal machine tomorrow which should 
be simpler (though a couple orders of magnitude slower) than my work behemoth...

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


[Lldb-commits] [lldb] lldb: add support for thread names on Windows (PR #74731)

2023-12-11 Thread Saleem Abdulrasool via lldb-commits


@@ -175,3 +179,30 @@ Status TargetThreadWindows::DoResume() {
 
   return Status();
 }
+
+const char *TargetThreadWindows::GetName() {
+  Log *log = GetLog(LLDBLog::Thread);
+  HMODULE hModule = ::LoadLibraryW(L"Kernel32.dll");
+  if (hModule) {
+auto GetThreadDescription =
+reinterpret_cast(
+::GetProcAddress(hModule, "GetThreadDescription"));

compnerd wrote:

If there is compatibility that we are concerned about, I think that we should 
consider falling back to more ... esoteric solutions.

```c++
__try {
  RaiseException(MS_VC_EXCEPTION, 0, sizeof(info) / sizeof(ULONG_PTR), 
(ULONG_PTR*));  
} __except (EXCEPTION_EXECUTE_HANDLER) {
} 
```

Should be far more portable and is what VS also uses.  This is documented at 
https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2015/debugger/how-to-set-a-thread-name-in-native-code?view=vs-2015=MSDN.

I would be okay with also raising the requirements to a newer version of 
Windows as 1607 is RS1 which makes it more than 8 years old at this point.

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


[Lldb-commits] [lldb] lldb: add support for thread names on Windows (PR #74731)

2023-12-11 Thread Saleem Abdulrasool via lldb-commits


@@ -175,3 +179,30 @@ Status TargetThreadWindows::DoResume() {
 
   return Status();
 }
+
+const char *TargetThreadWindows::GetName() {
+  Log *log = GetLog(LLDBLog::Thread);
+  HMODULE hModule = ::LoadLibraryW(L"Kernel32.dll");
+  if (hModule) {
+auto GetThreadDescription =

compnerd wrote:

This should be pulled out into a lambda and store the lookup rather than 
re-evaluating it each time.

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


[Lldb-commits] [lldb] lldb: add support for thread names on Windows (PR #74731)

2023-12-11 Thread Saleem Abdulrasool via lldb-commits


@@ -175,3 +179,30 @@ Status TargetThreadWindows::DoResume() {
 
   return Status();
 }
+
+const char *TargetThreadWindows::GetName() {
+  Log *log = GetLog(LLDBLog::Thread);
+  HMODULE hModule = ::LoadLibraryW(L"Kernel32.dll");
+  if (hModule) {
+auto GetThreadDescription =
+reinterpret_cast(
+::GetProcAddress(hModule, "GetThreadDescription"));
+LLDB_LOGF(log, "GetProcAddress: %p",
+  reinterpret_cast(GetThreadDescription));
+if (GetThreadDescription) {

compnerd wrote:

An early out here would be nice to reduce indentation.

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


[Lldb-commits] [lldb] Add a test for evicting unreachable modules from the global module cache (PR #74894)

2023-12-11 Thread via lldb-commits

https://github.com/jimingham updated 
https://github.com/llvm/llvm-project/pull/74894

>From 438d35a7a7fca454718062583f91776ca018b2b1 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Fri, 8 Dec 2023 14:43:14 -0800
Subject: [PATCH 1/3] Add a test for evicting unreachable modules from the
 global module cache.

---
 .../python_api/global_module_cache/Makefile   |   1 +
 .../TestGlobalModuleCache.py  | 110 ++
 .../global_module_cache/one-print.c   |   8 ++
 .../global_module_cache/two-print.c   |   9 ++
 4 files changed, 128 insertions(+)
 create mode 100644 lldb/test/API/python_api/global_module_cache/Makefile
 create mode 100644 
lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py
 create mode 100644 lldb/test/API/python_api/global_module_cache/one-print.c
 create mode 100644 lldb/test/API/python_api/global_module_cache/two-print.c

diff --git a/lldb/test/API/python_api/global_module_cache/Makefile 
b/lldb/test/API/python_api/global_module_cache/Makefile
new file mode 100644
index 00..22f1051530f871
--- /dev/null
+++ b/lldb/test/API/python_api/global_module_cache/Makefile
@@ -0,0 +1 @@
+include Makefile.rules
diff --git 
a/lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py 
b/lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py
new file mode 100644
index 00..ff74d09a128183
--- /dev/null
+++ b/lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py
@@ -0,0 +1,110 @@
+"""
+Test the use of the global module cache in lldb
+"""
+
+import lldb
+
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import os
+import shutil
+from pathlib import Path
+import time
+
+
+class GlobalModuleCacheTestCase(TestBase):
+# NO_DEBUG_INFO_TESTCASE = True
+
+def check_counter_var(self, thread, value):
+frame = thread.frames[0]
+var = frame.FindVariable("counter")
+self.assertTrue(var.GetError().Success(), "Got counter variable")
+self.assertEqual(var.GetValueAsUnsigned(), value, "This was one-print")
+
+def copy_to_main(self, src, dst):
+# We are relying on the source file being newer than the .o file from
+# a previous build, so sleep a bit here to ensure that the touch is 
later.
+time.sleep(2)
+try:
+shutil.copy(src, dst)
+except:
+self.fail(f"Could not copy {src} to {dst}")
+Path(dst).touch()
+
+# The rerun tests indicate rerunning on Windows doesn't really work, so
+# this one won't either.
+@skipIfWindows
+def test_OneTargetOneDebugger(self):
+# Make sure that if we have one target, and we run, then
+# change the binary and rerun, the binary (and any .o files
+# if using dwarf in .o file debugging) get removed from the
+# shared module cache.  They are no longer reachable.
+debug_style = self.getDebugInfo()
+
+# Before we do anything, clear the global module cache so we don't
+# see objects from other runs:
+lldb.SBDebugger.MemoryPressureDetected()
+
+# Set up the paths for our two versions of main.c:
+main_c_path = os.path.join(self.getBuildDir(), "main.c")
+one_print_path = os.path.join(self.getSourceDir(), "one-print.c")
+two_print_path = os.path.join(self.getSourceDir(), "two-print.c")
+main_filespec = lldb.SBFileSpec(main_c_path)
+
+# First copy the one-print.c to main.c in the build folder and
+# build our a.out from there:
+self.copy_to_main(one_print_path, main_c_path)
+self.build(dictionary={"C_SOURCES": main_c_path, "EXE": "a.out"})
+
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "return counter;", main_filespec
+)
+
+# Make sure we ran the version we intended here:
+self.check_counter_var(thread, 1)
+process.Kill()
+
+# Now copy two-print.c over main.c, rebuild, and rerun:
+# os.unlink(target.GetExecutable().fullpath)
+self.copy_to_main(two_print_path, main_c_path)
+
+self.build(dictionary={"C_SOURCES": main_c_path, "EXE": "a.out"})
+error = lldb.SBError()
+(_, process, thread, _) = lldbutil.run_to_breakpoint_do_run(self, 
target, bkpt)
+# In two-print.c counter will be 2:
+self.check_counter_var(thread, 2)
+
+num_a_dot_out_entries = 1
+# For dSYM's there will be two lines of output, one for the a.out and 
one
+# for the dSYM.
+if debug_style == "dsym":
+num_a_dot_out_entries += 1
+
+self.check_image_list_result(num_a_dot_out_entries, 1)
+
+def check_image_list_result(self, num_a_dot_out, num_main_dot_o):
+# Now look at the global module list, there should only be one a.out, 
and if we are
+# doing dwarf in .o file, there should 

[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

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

clayborg wrote:

> > > Sorry, it's been a while since I last reviewed this and I must admit I 
> > > forgot about this in the mean time. The only thing I'd like to check 
> > > before we can land this is to hear from @Michael137 who has been actively 
> > > working on FindTypes performance recently whether this aligns or clashes 
> > > with what he's been working on so we don't get a mid-air collision 
> > > between patches.
> > 
> > 
> > Sounds good, I look forward to hearing if this fixes the issues as well. 
> > Before this fix I ran a case where I did an expression like 
> > "MyClass::iterator" and before this fix, with linux and no accelerator 
> > tables, we would convert DWARF into clang AST types for over 2 million 
> > types, and after this fix it went down to 11. This was when debugging LLDB 
> > + LLVM + clang with debug info, so there were TONS of "iterator" entries in 
> > the manual DWARF index.
> > On Apple the type accelerator tables have the hash of the fully qualified 
> > name which can help reduce the number of types we parse, but we don't have 
> > this on linux even with DWARF5 + .debug_names
> 
> To add more context to @adrian-prantl's comment, we've been working on 
> reviving https://reviews.llvm.org/D101950, which changes the way we complete 
> record types. The main blocker was performance, because as you mention, we 
> often end up doing these expensive namespace searches, which gets much more 
> noticeable with D101950. The problem we saw was mostly triggered by the 
> second lookup that `-gsimple-template-names` does in `FindTypes`.
> 
> I applied your patch on top of D101950 and performance seems to be much 
> better (by 2 orders of magnitude). It did break some tests locally for me, so 
> I'm just skimming this patch to see what changed

All tests passed on my machine from with this, so you might try those tests 
without D101950 and see how things go? Happy to help if you need info on how to 
do things with the new lookups.

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

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

clayborg wrote:

> BTW, lets prefix the commit with `[lldb]` before merging

Do we need to fix this in the commit message when I squash? Or do I just update 
the title of this PR?

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


[Lldb-commits] [llvm] [lldb] [clang-tools-extra] [compiler-rt] [flang] [clang] [mlir] [Profile] Add binary profile correlation for code coverage. (PR #69493)

2023-12-11 Thread Fangrui Song via lldb-commits

MaskRay wrote:

We have this team: @llvm/pr-subscribers-pgo

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


[Lldb-commits] [lldb] 2e19760 - lldb: Cache string hash during ConstString pool queries/insertions

2023-12-11 Thread David Blaikie via lldb-commits

Author: David Blaikie
Date: 2023-12-12T00:07:08Z
New Revision: 2e197602305be18b963928e6ae024a004a95af6d

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

LOG: lldb: Cache string hash during ConstString pool queries/insertions

lldb was rehashing the string 3 times (once to determine which StringMap
to use, once to query the StringMap, once to insert) on insertion (twice
on successful lookup).

This patch allows the lldb to benefit from hash improvements in LLVM
(from djbHash to xxh3).

Though further changes would be needed to cache this value to disk - we
shouldn't rely on the StringMap::hash remaining the same in the
future/this value should not be serialized to disk. If we want cache
this value StringMap should take a hashing template parameter to allow
for a fixed hash to be requested.

Added: 


Modified: 
lldb/source/Utility/ConstString.cpp

Removed: 




diff  --git a/lldb/source/Utility/ConstString.cpp 
b/lldb/source/Utility/ConstString.cpp
index 4535771adfb735..ea897dc611cc94 100644
--- a/lldb/source/Utility/ConstString.cpp
+++ b/lldb/source/Utility/ConstString.cpp
@@ -77,10 +77,10 @@ class Pool {
 return 0;
   }
 
-  StringPoolValueType GetMangledCounterpart(const char *ccstr) const {
+  StringPoolValueType GetMangledCounterpart(const char *ccstr) {
 if (ccstr != nullptr) {
-  const uint8_t h = hash(llvm::StringRef(ccstr));
-  llvm::sys::SmartScopedReader rlock(m_string_pools[h].m_mutex);
+  const PoolEntry  = selectPool(llvm::StringRef(ccstr));
+  llvm::sys::SmartScopedReader rlock(pool.m_mutex);
   return GetStringMapEntryFromKeyData(ccstr).getValue();
 }
 return nullptr;
@@ -100,19 +100,20 @@ class Pool {
 
   const char *GetConstCStringWithStringRef(llvm::StringRef string_ref) {
 if (string_ref.data()) {
-  const uint8_t h = hash(string_ref);
+  const uint32_t string_hash = StringPool::hash(string_ref);
+  PoolEntry  = selectPool(string_hash);
 
   {
-llvm::sys::SmartScopedReader rlock(m_string_pools[h].m_mutex);
-auto it = m_string_pools[h].m_string_map.find(string_ref);
-if (it != m_string_pools[h].m_string_map.end())
+llvm::sys::SmartScopedReader rlock(pool.m_mutex);
+auto it = pool.m_string_map.find(string_ref, string_hash);
+if (it != pool.m_string_map.end())
   return it->getKeyData();
   }
 
-  llvm::sys::SmartScopedWriter wlock(m_string_pools[h].m_mutex);
+  llvm::sys::SmartScopedWriter wlock(pool.m_mutex);
   StringPoolEntryType  =
-  *m_string_pools[h]
-   .m_string_map.insert(std::make_pair(string_ref, nullptr))
+  *pool.m_string_map
+   .insert(std::make_pair(string_ref, nullptr), string_hash)
.first;
   return entry.getKeyData();
 }
@@ -125,12 +126,14 @@ class Pool {
 const char *demangled_ccstr = nullptr;
 
 {
-  const uint8_t h = hash(demangled);
-  llvm::sys::SmartScopedWriter wlock(m_string_pools[h].m_mutex);
+  const uint32_t demangled_hash = StringPool::hash(demangled);
+  PoolEntry  = selectPool(demangled_hash);
+  llvm::sys::SmartScopedWriter wlock(pool.m_mutex);
 
   // Make or update string pool entry with the mangled counterpart
-  StringPool  = m_string_pools[h].m_string_map;
-  StringPoolEntryType  = *map.try_emplace(demangled).first;
+  StringPool  = pool.m_string_map;
+  StringPoolEntryType  =
+  *map.try_emplace_with_hash(demangled, demangled_hash).first;
 
   entry.second = mangled_ccstr;
 
@@ -141,8 +144,8 @@ class Pool {
 {
   // Now assign the demangled const string as the counterpart of the
   // mangled const string...
-  const uint8_t h = hash(llvm::StringRef(mangled_ccstr));
-  llvm::sys::SmartScopedWriter wlock(m_string_pools[h].m_mutex);
+  PoolEntry  = selectPool(llvm::StringRef(mangled_ccstr));
+  llvm::sys::SmartScopedWriter wlock(pool.m_mutex);
   GetStringMapEntryFromKeyData(mangled_ccstr).setValue(demangled_ccstr);
 }
 
@@ -171,17 +174,20 @@ class Pool {
   }
 
 protected:
-  uint8_t hash(llvm::StringRef s) const {
-uint32_t h = llvm::djbHash(s);
-return ((h >> 24) ^ (h >> 16) ^ (h >> 8) ^ h) & 0xff;
-  }
-
   struct PoolEntry {
 mutable llvm::sys::SmartRWMutex m_mutex;
 StringPool m_string_map;
   };
 
   std::array m_string_pools;
+
+  PoolEntry (const llvm::StringRef ) {
+return selectPool(StringPool::hash(s));
+  }
+
+  PoolEntry (uint32_t h) {
+return m_string_pools[((h >> 24) ^ (h >> 16) ^ (h >> 8) ^ h) & 0xff];
+  }
 };
 
 // Frameworks and dylibs aren't supposed to have global C++ initializers so we
@@ -197,7 +203,7 @@ static Pool () {
   static Pool *g_string_pool = nullptr;
 
   

[Lldb-commits] [flang] [lldb] [llvm] [clang-tools-extra] [compiler-rt] [mlir] [clang] [Profile] Add binary profile correlation for code coverage. (PR #69493)

2023-12-11 Thread David Li via lldb-commits

david-xl wrote:

> @david-xl , Zequan posted an 
> [RFC](https://discourse.llvm.org/t/rfc-add-binary-profile-correlation-to-not-load-profile-metadata-sections-into-memory-at-runtime/74565/8)
>  for this. Is there a PGO tag, or something we can use to increase visibility 
> for PGO reviewers? I think most of the complexity for this new mode is in the 
> PGO code, so I think the best person to review it would be someone with an 
> interest in PGO.
> 
> I'll tag some folks, but let me know if there is a better way: @kparzysz 
> @snehasish

I am aware of this patch and it mostly look good to me. Since there is a long 
list of reviewers attached to this PR, better give more time for them to chime 
in.  I am quite busy early part of this week, but will try to give it another 
round by the end of the week if no one else beats me to it.

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-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 42bba97fc24f045f593fc26f998bac9b08633255 
9e826b1fc9dcc25186a9e7aef0998aab4978cfca -- 
lldb/test/API/functionalities/type_find_first/main.cpp 
lldb/include/lldb/Core/Module.h lldb/include/lldb/Core/ModuleList.h 
lldb/include/lldb/Symbol/CompilerDecl.h 
lldb/include/lldb/Symbol/CompilerDeclContext.h 
lldb/include/lldb/Symbol/SymbolFile.h 
lldb/include/lldb/Symbol/SymbolFileOnDemand.h lldb/include/lldb/Symbol/Type.h 
lldb/include/lldb/Symbol/TypeMap.h lldb/include/lldb/Symbol/TypeSystem.h 
lldb/include/lldb/lldb-forward.h lldb/include/lldb/lldb-private-enumerations.h 
lldb/source/API/SBModule.cpp lldb/source/API/SBTarget.cpp 
lldb/source/Commands/CommandObjectMemory.cpp 
lldb/source/Commands/CommandObjectTarget.cpp lldb/source/Core/Module.cpp 
lldb/source/Core/ModuleList.cpp lldb/source/DataFormatters/TypeFormat.cpp 
lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp 
lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
 lldb/source/Plugins/LanguageRuntime/ObjC/ObjCLanguageRuntime.cpp 
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp 
lldb/source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.h 
lldb/source/Plugins/SymbolFile/CTF/SymbolFileCTF.cpp 
lldb/source/Plugins/SymbolFile/CTF/SymbolFileCTF.h 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h 
lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp 
lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h 
lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp 
lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h 
lldb/source/Symbol/CompilerDecl.cpp lldb/source/Symbol/CompilerDeclContext.cpp 
lldb/source/Symbol/SymbolFile.cpp lldb/source/Symbol/SymbolFileOnDemand.cpp 
lldb/source/Symbol/Type.cpp lldb/source/Symbol/TypeMap.cpp 
lldb/source/Symbol/TypeSystem.cpp lldb/source/Target/Language.cpp 
lldb/test/API/lang/cpp/unique-types4/main.cpp lldb/tools/lldb-test/lldb-test.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index 345422f565..c3ac830ce7 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -2075,7 +2075,8 @@ protected:
   }
   if (INTERRUPT_REQUESTED(GetDebugger(),
   "Interrupted in dump all symtabs with {0} "
-  "of {1} dumped.", num_dumped, num_modules))
+  "of {1} dumped.",
+  num_dumped, num_modules))
 break;
 
   num_dumped++;
@@ -2103,9 +2104,10 @@ protected:
 result.GetOutputStream().EOL();
 result.GetOutputStream().EOL();
   }
-  if (INTERRUPT_REQUESTED(GetDebugger(),
-"Interrupted in dump symtab list with {0} of {1} dumped.",
-num_dumped, num_matches))
+  if (INTERRUPT_REQUESTED(
+  GetDebugger(),
+  "Interrupted in dump symtab list with {0} of {1} 
dumped.",
+  num_dumped, num_matches))
 break;
 
   num_dumped++;
@@ -2166,9 +2168,10 @@ protected:
   result.GetOutputStream().Format("Dumping sections for {0} modules.\n",
   num_modules);
   for (size_t image_idx = 0; image_idx < num_modules; ++image_idx) {
-if (INTERRUPT_REQUESTED(GetDebugger(),
-  "Interrupted in dump all sections with {0} of {1} dumped",
-  image_idx, num_modules))
+if (INTERRUPT_REQUESTED(
+GetDebugger(),
+"Interrupted in dump all sections with {0} of {1} dumped",
+image_idx, num_modules))
   break;
 
 num_dumped++;
@@ -2187,9 +2190,10 @@ protected:
 FindModulesByName(target, arg_cstr, module_list, true);
 if (num_matches > 0) {
   for (size_t i = 0; i < num_matches; ++i) {
-if (INTERRUPT_REQUESTED(GetDebugger(),
-  "Interrupted in dump section list with {0} of {1} dumped.",
-  i, num_matches))
+if (INTERRUPT_REQUESTED(
+GetDebugger(),
+ 

[Lldb-commits] [lldb] Add a test for evicting unreachable modules from the global module cache (PR #74894)

2023-12-11 Thread via lldb-commits

github-actions[bot] wrote:




:warning: Python code formatter, darker found issues in your code. :warning:



You can test this locally with the following command:


``bash
darker --check --diff -r 
44dc1e0baae7c4b8a02ba06dcf396d3d452aa873...684cee4a363c87c6b2cfa0776adb7c5923a0f6b6
 lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py
``





View the diff from darker here.


``diff
--- TestGlobalModuleCache.py2023-12-11 23:54:38.00 +
+++ TestGlobalModuleCache.py2023-12-11 23:57:25.210256 +
@@ -39,11 +39,11 @@
 self.do_test_one_debugger(True)
 
 @expectedFailureAll
 def test_TwoTargetsOneDebugger(self):
 self.do_test_one_debugger(False)
-
+
 def do_test_one_debugger(self, one_target):
 # Make sure that if we have one target, and we run, then
 # change the binary and rerun, the binary (and any .o files
 # if using dwarf in .o file debugging) get removed from the
 # shared module cache.  They are no longer reachable.
@@ -77,11 +77,13 @@
 self.copy_to_main(two_print_path, main_c_path)
 
 self.build(dictionary={"C_SOURCES": main_c_path, "EXE": "a.out"})
 error = lldb.SBError()
 if one_target:
-(_, process, thread, _) = lldbutil.run_to_breakpoint_do_run(self, 
target, bkpt)
+(_, process, thread, _) = lldbutil.run_to_breakpoint_do_run(
+self, target, bkpt
+)
 else:
 (target2, process2, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(
 self, "return counter;", main_filespec
 )
 
@@ -98,11 +100,11 @@
 # for the dSYM.
 if debug_style == "dsym":
 num_a_dot_out_entries += 1
 
 self.check_image_list_result(num_a_dot_out_entries, 1)
-
+
 def check_image_list_result(self, num_a_dot_out, num_main_dot_o):
 # Now look at the global module list, there should only be one a.out, 
and if we are
 # doing dwarf in .o file, there should only be one .o file:
 image_cmd_result = lldb.SBCommandReturnObject()
 interp = self.dbg.GetCommandInterpreter()

``




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


[Lldb-commits] [lldb] Add a test for evicting unreachable modules from the global module cache (PR #74894)

2023-12-11 Thread via lldb-commits

jimingham wrote:

I added a test for the case where one target has the old version and another 
target has the new one.  In this case, I don't think (short of 
MemoryPressureDetected by hand) that we'll ever get rid of these unreachable 
Modules.

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


[Lldb-commits] [lldb] Add a test for evicting unreachable modules from the global module cache (PR #74894)

2023-12-11 Thread via lldb-commits

https://github.com/jimingham updated 
https://github.com/llvm/llvm-project/pull/74894

>From 438d35a7a7fca454718062583f91776ca018b2b1 Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Fri, 8 Dec 2023 14:43:14 -0800
Subject: [PATCH 1/2] Add a test for evicting unreachable modules from the
 global module cache.

---
 .../python_api/global_module_cache/Makefile   |   1 +
 .../TestGlobalModuleCache.py  | 110 ++
 .../global_module_cache/one-print.c   |   8 ++
 .../global_module_cache/two-print.c   |   9 ++
 4 files changed, 128 insertions(+)
 create mode 100644 lldb/test/API/python_api/global_module_cache/Makefile
 create mode 100644 
lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py
 create mode 100644 lldb/test/API/python_api/global_module_cache/one-print.c
 create mode 100644 lldb/test/API/python_api/global_module_cache/two-print.c

diff --git a/lldb/test/API/python_api/global_module_cache/Makefile 
b/lldb/test/API/python_api/global_module_cache/Makefile
new file mode 100644
index 0..22f1051530f87
--- /dev/null
+++ b/lldb/test/API/python_api/global_module_cache/Makefile
@@ -0,0 +1 @@
+include Makefile.rules
diff --git 
a/lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py 
b/lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py
new file mode 100644
index 0..ff74d09a12818
--- /dev/null
+++ b/lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py
@@ -0,0 +1,110 @@
+"""
+Test the use of the global module cache in lldb
+"""
+
+import lldb
+
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import os
+import shutil
+from pathlib import Path
+import time
+
+
+class GlobalModuleCacheTestCase(TestBase):
+# NO_DEBUG_INFO_TESTCASE = True
+
+def check_counter_var(self, thread, value):
+frame = thread.frames[0]
+var = frame.FindVariable("counter")
+self.assertTrue(var.GetError().Success(), "Got counter variable")
+self.assertEqual(var.GetValueAsUnsigned(), value, "This was one-print")
+
+def copy_to_main(self, src, dst):
+# We are relying on the source file being newer than the .o file from
+# a previous build, so sleep a bit here to ensure that the touch is 
later.
+time.sleep(2)
+try:
+shutil.copy(src, dst)
+except:
+self.fail(f"Could not copy {src} to {dst}")
+Path(dst).touch()
+
+# The rerun tests indicate rerunning on Windows doesn't really work, so
+# this one won't either.
+@skipIfWindows
+def test_OneTargetOneDebugger(self):
+# Make sure that if we have one target, and we run, then
+# change the binary and rerun, the binary (and any .o files
+# if using dwarf in .o file debugging) get removed from the
+# shared module cache.  They are no longer reachable.
+debug_style = self.getDebugInfo()
+
+# Before we do anything, clear the global module cache so we don't
+# see objects from other runs:
+lldb.SBDebugger.MemoryPressureDetected()
+
+# Set up the paths for our two versions of main.c:
+main_c_path = os.path.join(self.getBuildDir(), "main.c")
+one_print_path = os.path.join(self.getSourceDir(), "one-print.c")
+two_print_path = os.path.join(self.getSourceDir(), "two-print.c")
+main_filespec = lldb.SBFileSpec(main_c_path)
+
+# First copy the one-print.c to main.c in the build folder and
+# build our a.out from there:
+self.copy_to_main(one_print_path, main_c_path)
+self.build(dictionary={"C_SOURCES": main_c_path, "EXE": "a.out"})
+
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "return counter;", main_filespec
+)
+
+# Make sure we ran the version we intended here:
+self.check_counter_var(thread, 1)
+process.Kill()
+
+# Now copy two-print.c over main.c, rebuild, and rerun:
+# os.unlink(target.GetExecutable().fullpath)
+self.copy_to_main(two_print_path, main_c_path)
+
+self.build(dictionary={"C_SOURCES": main_c_path, "EXE": "a.out"})
+error = lldb.SBError()
+(_, process, thread, _) = lldbutil.run_to_breakpoint_do_run(self, 
target, bkpt)
+# In two-print.c counter will be 2:
+self.check_counter_var(thread, 2)
+
+num_a_dot_out_entries = 1
+# For dSYM's there will be two lines of output, one for the a.out and 
one
+# for the dSYM.
+if debug_style == "dsym":
+num_a_dot_out_entries += 1
+
+self.check_image_list_result(num_a_dot_out_entries, 1)
+
+def check_image_list_result(self, num_a_dot_out, num_main_dot_o):
+# Now look at the global module list, there should only be one a.out, 
and if we are
+# doing dwarf in .o file, there should only 

[Lldb-commits] [clang-tools-extra] [flang] [clang] [llvm] [compiler-rt] [lldb] [openmp] [mlir] [lld] [libc] [libcxx] fix issue 73559. (PR #74926)

2023-12-11 Thread via lldb-commits

ChipsSpectre wrote:

The pull request is updated now, and passing tests and formatting checks.

Is it ready to be merged in its new state?

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


[Lldb-commits] [clang-tools-extra] [flang] [clang] [llvm] [compiler-rt] [lldb] [openmp] [mlir] [lld] [libc] [libcxx] fix issue 73559. (PR #74926)

2023-12-11 Thread via lldb-commits

https://github.com/ChipsSpectre updated 
https://github.com/llvm/llvm-project/pull/74926

>From 8269060e6b50721a847742ff8d0af2c819e52578 Mon Sep 17 00:00:00 2001
From: ChipsSpectre 
Date: Sat, 9 Dec 2023 12:07:02 +0100
Subject: [PATCH 1/4] fix issue 73559.

---
 clang/lib/Parse/ParseDecl.cpp| 3 ++-
 clang/lib/Parse/ParseDeclCXX.cpp | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index ece3698967e2f6..5d1c19ae07cb54 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -3483,7 +3483,8 @@ void Parser::ParseDeclarationSpecifiers(
 
 case tok::coloncolon: // ::foo::bar
   // C++ scope specifier.  Annotate and loop, or bail out on error.
-  if (TryAnnotateCXXScopeToken(EnteringContext)) {
+  if (getLangOpts().CPlusPlus &&
+  TryAnnotateCXXScopeToken(EnteringContext)) {
 if (!DS.hasTypeSpecifier())
   DS.SetTypeSpecError();
 goto DoneWithDeclSpec;
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index 910112ecae964c..eba7ea65beee94 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -2702,7 +2702,7 @@ Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
   bool MalformedTypeSpec = false;
   if (!TemplateInfo.Kind &&
   Tok.isOneOf(tok::identifier, tok::coloncolon, tok::kw___super)) {
-if (TryAnnotateCXXScopeToken())
+if (getLangOpts().CPlusPlus && TryAnnotateCXXScopeToken())
   MalformedTypeSpec = true;
 
 bool isAccessDecl;

>From e8419c3750f7b1cf877b042942204abaab48344b Mon Sep 17 00:00:00 2001
From: ChipsSpectre 
Date: Mon, 11 Dec 2023 22:31:10 +0100
Subject: [PATCH 2/4] address review comments.

---
 clang/docs/ReleaseNotes.rst  | 2 ++
 clang/lib/Parse/ParseDeclCXX.cpp | 6 --
 clang/test/Parser/cxx-in-c.c | 1 +
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 6e4009deaf8746..39dd8c68dbbcb1 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -641,6 +641,8 @@ Bug Fixes in This Version
   Fixes (`#67317 `_)
 - Clang now properly diagnoses use of stand-alone OpenMP directives after a
   label (including ``case`` or ``default`` labels).
+- Fix crash when using C++ only tokens like *::* in C compiler clang.
+  Fixes (`#73559 https://github.com/llvm/llvm-project/issues/73559`_)
 
   Before:
 
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index eba7ea65beee94..89a97cc96111d8 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -2678,7 +2678,9 @@ Parser::DeclGroupPtrTy
 Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
ParsedAttributes ,
const ParsedTemplateInfo ,
-   ParsingDeclRAIIObject *TemplateDiags) {
+   ParsingDeclRAIIObject *TemplateDiags) { 
 
+  assert(getLangOpts().CPlusPlus &&
+ "Call sites of this function should be guarded by checking for C++"); 
 
   if (Tok.is(tok::at)) {
 if (getLangOpts().ObjC && NextToken().isObjCAtKeyword(tok::objc_defs))
   Diag(Tok, diag::err_at_defs_cxx);
@@ -2702,7 +2704,7 @@ Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
   bool MalformedTypeSpec = false;
   if (!TemplateInfo.Kind &&
   Tok.isOneOf(tok::identifier, tok::coloncolon, tok::kw___super)) {
-if (getLangOpts().CPlusPlus && TryAnnotateCXXScopeToken())
+if (TryAnnotateCXXScopeToken())
   MalformedTypeSpec = true;
 
 bool isAccessDecl;
diff --git a/clang/test/Parser/cxx-in-c.c b/clang/test/Parser/cxx-in-c.c
index f5fa39bd0cb99b..bd304260571c4d 100644
--- a/clang/test/Parser/cxx-in-c.c
+++ b/clang/test/Parser/cxx-in-c.c
@@ -3,3 +3,4 @@
 // PR9137
 void f0(int x) : {}; // expected-error{{expected function body after function 
declarator}}
 void f1(int x) try {}; // expected-error{{expected function body after 
function declarator}}
+::; // expected-error{{expected that double colon marker does not appear in c}}

>From ac0d1c6d440b9c94af9bf95dc27687e2437ce39b Mon Sep 17 00:00:00 2001
From: ChipsSpectre 
Date: Mon, 11 Dec 2023 22:35:17 +0100
Subject: [PATCH 3/4] enforce coding style

---
 clang/lib/Parse/ParseDeclCXX.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index 89a97cc96111d8..1cf16a752cfcdc 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -2678,9 +2678,9 @@ Parser::DeclGroupPtrTy
 Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
ParsedAttributes ,
const 

[Lldb-commits] [lldb] [lldb] Disable new TestLocationListLookup when clang version is <= 11 (PR #75102)

2023-12-11 Thread Augusto Noronha via lldb-commits

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


[Lldb-commits] [lldb] a37fa2a - [lldb] Disable new TestLocationListLookup when clang version is <= 11 (#75102)

2023-12-11 Thread via lldb-commits

Author: Augusto Noronha
Date: 2023-12-11T14:40:43-08:00
New Revision: a37fa2a8e1c827f1ff04b0b13b83cf97eefe74c0

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

LOG: [lldb] Disable new TestLocationListLookup when clang version is <= 11 
(#75102)

The newly introduced LocationListLookupTestCase.test_loclist_expr test
fails with older clangs.

Added: 


Modified: 
lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py 
b/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
index ccee3bfde3f5de..feea14ff355e82 100644
--- 
a/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
+++ 
b/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
@@ -43,6 +43,7 @@ def test_loclist_frame_var(self):
 self.build()
 self.check_local_vars(self.launch(), check_expr=False)
 
+@skipIf(compiler="clang", compiler_version=["<=", "11.0"])
 @skipUnlessDarwin
 def test_loclist_expr(self):
 self.build()



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


[Lldb-commits] [lldb] Add a test for evicting unreachable modules from the global module cache (PR #74894)

2023-12-11 Thread via lldb-commits

jimingham wrote:

> > Note, I thought about adding an `SBDebugger::GetSharedModules or something, 
> > but I don't actually think that's a good thing to give external access to. 
> > Some day we should make an SBTestAPI with some useful for testing but not 
> > for the SB API library so we can make this sort of testing easier, but for 
> > this test grubbing the command output is not all that bad.
> 
> I wouldn't mind exposing such an API for the global module list as a static 
> functions (get count + get at index) on SBDebugger. One issue is that only 
> real modules will show up here. This works fine for all modules for Darwin as 
> executables, dSYM files and the .o files are all represented each by a 
> lldb_private::Module. Not true for .dwo files though as they share the 
> original module for the executable and only create a new ObjectFile, not a 
> new Module for each. Not a big deal though.
> 
> This API would be useful for testing and also for people to know what modules 
> are currently in the global module cache taking up memory in the LLDB 
> process. To test this you might be able to run your first executable and then 
> check the number of shared modules and access them if needed then run:
> 
> ```
> static void SBDebugger::MemoryPressureDetected();
> ```
> 
> As this used to get rid of orphaned modules in the past and I think it still 
> does, then you could check this shared module count and list again after 
> creating and running the second executable to see what you found.

If I knew how to hand out SBReadOnlyModule objects, I think this would be a 
fine API.  But I am wary of adding an API where one SBDebugger could 
inadvertently change another SBDebugger's environment behind its back.  We do 
do allow this by accident today, for instance have Debugger1 turn off "external 
symbol search" but then Debugger2 has it on, and loads the same module as 
Debugger1, forcing symbols on Debugger1.

But IMO that's a bug, and I'd rather not add more ways to write that bug.

Fortunately, the output of `image list -g` is super easy to parse, so I don't 
need the API for this investigation.

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


[Lldb-commits] [compiler-rt] [clang] [flang] [clang-tools-extra] [mlir] [lldb] [llvm] [Profile] Add binary profile correlation for code coverage. (PR #69493)

2023-12-11 Thread Reid Kleckner via lldb-commits

rnk wrote:

@david-xl , Zequan posted an 
[RFC](https://discourse.llvm.org/t/rfc-add-binary-profile-correlation-to-not-load-profile-metadata-sections-into-memory-at-runtime/74565/8)
 for this. Is there a PGO tag, or something we can use to increase visibility 
for PGO reviewers? I think most of the complexity for this new mode is in the 
PGO code, so I think the best person to review it would be someone with an 
interest in PGO.

I'll tag some folks, but let me know if there is a better way: @kparzysz 
@snehasish 

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


[Lldb-commits] [lldb] [lldb] Disable new TestLocationListLookup when clang version is <= 11 (PR #75102)

2023-12-11 Thread Augusto Noronha via lldb-commits

https://github.com/augusto2112 updated 
https://github.com/llvm/llvm-project/pull/75102

>From be91ba6b5b411e2fc6b9a7b49324ef5b20c9e2ed Mon Sep 17 00:00:00 2001
From: Augusto Noronha 
Date: Mon, 11 Dec 2023 13:38:04 -0800
Subject: [PATCH] [lldb] Disable new TestLocationListLookup when clang version
 is <= 11

The newly introduced LocationListLookupTestCase.test_loclist_expr test fails 
with older clangs.
---
 .../location-list-lookup/TestLocationListLookup.py   | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py 
b/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
index ccee3bfde3f5de..feea14ff355e82 100644
--- 
a/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
+++ 
b/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
@@ -43,6 +43,7 @@ def test_loclist_frame_var(self):
 self.build()
 self.check_local_vars(self.launch(), check_expr=False)
 
+@skipIf(compiler="clang", compiler_version=["<=", "11.0"])
 @skipUnlessDarwin
 def test_loclist_expr(self):
 self.build()

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


[Lldb-commits] [compiler-rt] [llvm] [lld] [clang] [flang] [libc] [openmp] [clang-tools-extra] [libcxx] [lldb] [mlir] fix issue 73559. (PR #74926)

2023-12-11 Thread via lldb-commits

https://github.com/ChipsSpectre updated 
https://github.com/llvm/llvm-project/pull/74926

>From 8269060e6b50721a847742ff8d0af2c819e52578 Mon Sep 17 00:00:00 2001
From: ChipsSpectre 
Date: Sat, 9 Dec 2023 12:07:02 +0100
Subject: [PATCH 1/3] fix issue 73559.

---
 clang/lib/Parse/ParseDecl.cpp| 3 ++-
 clang/lib/Parse/ParseDeclCXX.cpp | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index ece3698967e2f6..5d1c19ae07cb54 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -3483,7 +3483,8 @@ void Parser::ParseDeclarationSpecifiers(
 
 case tok::coloncolon: // ::foo::bar
   // C++ scope specifier.  Annotate and loop, or bail out on error.
-  if (TryAnnotateCXXScopeToken(EnteringContext)) {
+  if (getLangOpts().CPlusPlus &&
+  TryAnnotateCXXScopeToken(EnteringContext)) {
 if (!DS.hasTypeSpecifier())
   DS.SetTypeSpecError();
 goto DoneWithDeclSpec;
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index 910112ecae964c..eba7ea65beee94 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -2702,7 +2702,7 @@ Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
   bool MalformedTypeSpec = false;
   if (!TemplateInfo.Kind &&
   Tok.isOneOf(tok::identifier, tok::coloncolon, tok::kw___super)) {
-if (TryAnnotateCXXScopeToken())
+if (getLangOpts().CPlusPlus && TryAnnotateCXXScopeToken())
   MalformedTypeSpec = true;
 
 bool isAccessDecl;

>From e8419c3750f7b1cf877b042942204abaab48344b Mon Sep 17 00:00:00 2001
From: ChipsSpectre 
Date: Mon, 11 Dec 2023 22:31:10 +0100
Subject: [PATCH 2/3] address review comments.

---
 clang/docs/ReleaseNotes.rst  | 2 ++
 clang/lib/Parse/ParseDeclCXX.cpp | 6 --
 clang/test/Parser/cxx-in-c.c | 1 +
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 6e4009deaf8746..39dd8c68dbbcb1 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -641,6 +641,8 @@ Bug Fixes in This Version
   Fixes (`#67317 `_)
 - Clang now properly diagnoses use of stand-alone OpenMP directives after a
   label (including ``case`` or ``default`` labels).
+- Fix crash when using C++ only tokens like *::* in C compiler clang.
+  Fixes (`#73559 https://github.com/llvm/llvm-project/issues/73559`_)
 
   Before:
 
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index eba7ea65beee94..89a97cc96111d8 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -2678,7 +2678,9 @@ Parser::DeclGroupPtrTy
 Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
ParsedAttributes ,
const ParsedTemplateInfo ,
-   ParsingDeclRAIIObject *TemplateDiags) {
+   ParsingDeclRAIIObject *TemplateDiags) { 
 
+  assert(getLangOpts().CPlusPlus &&
+ "Call sites of this function should be guarded by checking for C++"); 
 
   if (Tok.is(tok::at)) {
 if (getLangOpts().ObjC && NextToken().isObjCAtKeyword(tok::objc_defs))
   Diag(Tok, diag::err_at_defs_cxx);
@@ -2702,7 +2704,7 @@ Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
   bool MalformedTypeSpec = false;
   if (!TemplateInfo.Kind &&
   Tok.isOneOf(tok::identifier, tok::coloncolon, tok::kw___super)) {
-if (getLangOpts().CPlusPlus && TryAnnotateCXXScopeToken())
+if (TryAnnotateCXXScopeToken())
   MalformedTypeSpec = true;
 
 bool isAccessDecl;
diff --git a/clang/test/Parser/cxx-in-c.c b/clang/test/Parser/cxx-in-c.c
index f5fa39bd0cb99b..bd304260571c4d 100644
--- a/clang/test/Parser/cxx-in-c.c
+++ b/clang/test/Parser/cxx-in-c.c
@@ -3,3 +3,4 @@
 // PR9137
 void f0(int x) : {}; // expected-error{{expected function body after function 
declarator}}
 void f1(int x) try {}; // expected-error{{expected function body after 
function declarator}}
+::; // expected-error{{expected that double colon marker does not appear in c}}

>From ac0d1c6d440b9c94af9bf95dc27687e2437ce39b Mon Sep 17 00:00:00 2001
From: ChipsSpectre 
Date: Mon, 11 Dec 2023 22:35:17 +0100
Subject: [PATCH 3/3] enforce coding style

---
 clang/lib/Parse/ParseDeclCXX.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index 89a97cc96111d8..1cf16a752cfcdc 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -2678,9 +2678,9 @@ Parser::DeclGroupPtrTy
 Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
ParsedAttributes ,
const 

[Lldb-commits] [compiler-rt] [llvm] [lld] [clang] [flang] [libc] [openmp] [clang-tools-extra] [libcxx] [lldb] [mlir] fix issue 73559. (PR #74926)

2023-12-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 f92d970c8cc27747478abb7df66bb8b6701cea49 
e8419c3750f7b1cf877b042942204abaab48344b -- clang/lib/Parse/ParseDecl.cpp 
clang/lib/Parse/ParseDeclCXX.cpp clang/test/Parser/cxx-in-c.c
``





View the diff from clang-format here.


``diff
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index 89a97cc961..1cf16a752c 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -2678,9 +2678,9 @@ Parser::DeclGroupPtrTy
 Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
ParsedAttributes ,
const ParsedTemplateInfo ,
-   ParsingDeclRAIIObject *TemplateDiags) { 
 
+   ParsingDeclRAIIObject *TemplateDiags) {
   assert(getLangOpts().CPlusPlus &&
- "Call sites of this function should be guarded by checking for C++"); 
 
+ "Call sites of this function should be guarded by checking for C++");
   if (Tok.is(tok::at)) {
 if (getLangOpts().ObjC && NextToken().isObjCAtKeyword(tok::objc_defs))
   Diag(Tok, diag::err_at_defs_cxx);

``




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


[Lldb-commits] [compiler-rt] [llvm] [lld] [clang] [flang] [libc] [openmp] [clang-tools-extra] [libcxx] [lldb] [mlir] fix issue 73559. (PR #74926)

2023-12-11 Thread via lldb-commits

https://github.com/ChipsSpectre updated 
https://github.com/llvm/llvm-project/pull/74926

>From 8269060e6b50721a847742ff8d0af2c819e52578 Mon Sep 17 00:00:00 2001
From: ChipsSpectre 
Date: Sat, 9 Dec 2023 12:07:02 +0100
Subject: [PATCH 1/2] fix issue 73559.

---
 clang/lib/Parse/ParseDecl.cpp| 3 ++-
 clang/lib/Parse/ParseDeclCXX.cpp | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index ece3698967e2f6..5d1c19ae07cb54 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -3483,7 +3483,8 @@ void Parser::ParseDeclarationSpecifiers(
 
 case tok::coloncolon: // ::foo::bar
   // C++ scope specifier.  Annotate and loop, or bail out on error.
-  if (TryAnnotateCXXScopeToken(EnteringContext)) {
+  if (getLangOpts().CPlusPlus &&
+  TryAnnotateCXXScopeToken(EnteringContext)) {
 if (!DS.hasTypeSpecifier())
   DS.SetTypeSpecError();
 goto DoneWithDeclSpec;
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index 910112ecae964c..eba7ea65beee94 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -2702,7 +2702,7 @@ Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
   bool MalformedTypeSpec = false;
   if (!TemplateInfo.Kind &&
   Tok.isOneOf(tok::identifier, tok::coloncolon, tok::kw___super)) {
-if (TryAnnotateCXXScopeToken())
+if (getLangOpts().CPlusPlus && TryAnnotateCXXScopeToken())
   MalformedTypeSpec = true;
 
 bool isAccessDecl;

>From e8419c3750f7b1cf877b042942204abaab48344b Mon Sep 17 00:00:00 2001
From: ChipsSpectre 
Date: Mon, 11 Dec 2023 22:31:10 +0100
Subject: [PATCH 2/2] address review comments.

---
 clang/docs/ReleaseNotes.rst  | 2 ++
 clang/lib/Parse/ParseDeclCXX.cpp | 6 --
 clang/test/Parser/cxx-in-c.c | 1 +
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 6e4009deaf8746..39dd8c68dbbcb1 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -641,6 +641,8 @@ Bug Fixes in This Version
   Fixes (`#67317 `_)
 - Clang now properly diagnoses use of stand-alone OpenMP directives after a
   label (including ``case`` or ``default`` labels).
+- Fix crash when using C++ only tokens like *::* in C compiler clang.
+  Fixes (`#73559 https://github.com/llvm/llvm-project/issues/73559`_)
 
   Before:
 
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index eba7ea65beee94..89a97cc96111d8 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -2678,7 +2678,9 @@ Parser::DeclGroupPtrTy
 Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
ParsedAttributes ,
const ParsedTemplateInfo ,
-   ParsingDeclRAIIObject *TemplateDiags) {
+   ParsingDeclRAIIObject *TemplateDiags) { 
 
+  assert(getLangOpts().CPlusPlus &&
+ "Call sites of this function should be guarded by checking for C++"); 
 
   if (Tok.is(tok::at)) {
 if (getLangOpts().ObjC && NextToken().isObjCAtKeyword(tok::objc_defs))
   Diag(Tok, diag::err_at_defs_cxx);
@@ -2702,7 +2704,7 @@ Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
   bool MalformedTypeSpec = false;
   if (!TemplateInfo.Kind &&
   Tok.isOneOf(tok::identifier, tok::coloncolon, tok::kw___super)) {
-if (getLangOpts().CPlusPlus && TryAnnotateCXXScopeToken())
+if (TryAnnotateCXXScopeToken())
   MalformedTypeSpec = true;
 
 bool isAccessDecl;
diff --git a/clang/test/Parser/cxx-in-c.c b/clang/test/Parser/cxx-in-c.c
index f5fa39bd0cb99b..bd304260571c4d 100644
--- a/clang/test/Parser/cxx-in-c.c
+++ b/clang/test/Parser/cxx-in-c.c
@@ -3,3 +3,4 @@
 // PR9137
 void f0(int x) : {}; // expected-error{{expected function body after function 
declarator}}
 void f1(int x) try {}; // expected-error{{expected function body after 
function declarator}}
+::; // expected-error{{expected that double colon marker does not appear in c}}

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


[Lldb-commits] [lldb] [lldb] Disable new TestLocationListLookup when clang version is <= 11 (PR #75102)

2023-12-11 Thread via lldb-commits

github-actions[bot] wrote:




:warning: Python code formatter, darker found issues in your code. :warning:



You can test this locally with the following command:


``bash
darker --check --diff -r 
13ef4fec26650a93b57709a23a3392582825afe7...0ec0f8ddf505ad30f8684e9452ebc4524f50a4b4
 lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
``





View the diff from darker here.


``diff
--- TestLocationListLookup.py   2023-12-11 21:29:25.00 +
+++ TestLocationListLookup.py   2023-12-11 21:33:11.003085 +
@@ -41,10 +41,10 @@
 @skipIfDarwin
 def test_loclist_frame_var(self):
 self.build()
 self.check_local_vars(self.launch(), check_expr=False)
 
-@skipIf(compiler="clang", compiler_version=['<=', '11.0'])
+@skipIf(compiler="clang", compiler_version=["<=", "11.0"])
 @skipUnlessDarwin
 def test_loclist_expr(self):
 self.build()
 self.check_local_vars(self.launch(), check_expr=True)

``




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


[Lldb-commits] [compiler-rt] [llvm] [lld] [clang] [flang] [libc] [clang-tools-extra] [libcxx] [lldb] fix issue 73559. (PR #74926)

2023-12-11 Thread via lldb-commits

https://github.com/ChipsSpectre updated 
https://github.com/llvm/llvm-project/pull/74926

>From 8269060e6b50721a847742ff8d0af2c819e52578 Mon Sep 17 00:00:00 2001
From: ChipsSpectre 
Date: Sat, 9 Dec 2023 12:07:02 +0100
Subject: [PATCH 1/2] fix issue 73559.

---
 clang/lib/Parse/ParseDecl.cpp| 3 ++-
 clang/lib/Parse/ParseDeclCXX.cpp | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index ece3698967e2f..5d1c19ae07cb5 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -3483,7 +3483,8 @@ void Parser::ParseDeclarationSpecifiers(
 
 case tok::coloncolon: // ::foo::bar
   // C++ scope specifier.  Annotate and loop, or bail out on error.
-  if (TryAnnotateCXXScopeToken(EnteringContext)) {
+  if (getLangOpts().CPlusPlus &&
+  TryAnnotateCXXScopeToken(EnteringContext)) {
 if (!DS.hasTypeSpecifier())
   DS.SetTypeSpecError();
 goto DoneWithDeclSpec;
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index 910112ecae964..eba7ea65beee9 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -2702,7 +2702,7 @@ Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
   bool MalformedTypeSpec = false;
   if (!TemplateInfo.Kind &&
   Tok.isOneOf(tok::identifier, tok::coloncolon, tok::kw___super)) {
-if (TryAnnotateCXXScopeToken())
+if (getLangOpts().CPlusPlus && TryAnnotateCXXScopeToken())
   MalformedTypeSpec = true;
 
 bool isAccessDecl;

>From e8419c3750f7b1cf877b042942204abaab48344b Mon Sep 17 00:00:00 2001
From: ChipsSpectre 
Date: Mon, 11 Dec 2023 22:31:10 +0100
Subject: [PATCH 2/2] address review comments.

---
 clang/docs/ReleaseNotes.rst  | 2 ++
 clang/lib/Parse/ParseDeclCXX.cpp | 6 --
 clang/test/Parser/cxx-in-c.c | 1 +
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 6e4009deaf874..39dd8c68dbbcb 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -641,6 +641,8 @@ Bug Fixes in This Version
   Fixes (`#67317 `_)
 - Clang now properly diagnoses use of stand-alone OpenMP directives after a
   label (including ``case`` or ``default`` labels).
+- Fix crash when using C++ only tokens like *::* in C compiler clang.
+  Fixes (`#73559 https://github.com/llvm/llvm-project/issues/73559`_)
 
   Before:
 
diff --git a/clang/lib/Parse/ParseDeclCXX.cpp b/clang/lib/Parse/ParseDeclCXX.cpp
index eba7ea65beee9..89a97cc96111d 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -2678,7 +2678,9 @@ Parser::DeclGroupPtrTy
 Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
ParsedAttributes ,
const ParsedTemplateInfo ,
-   ParsingDeclRAIIObject *TemplateDiags) {
+   ParsingDeclRAIIObject *TemplateDiags) { 
 
+  assert(getLangOpts().CPlusPlus &&
+ "Call sites of this function should be guarded by checking for C++"); 
 
   if (Tok.is(tok::at)) {
 if (getLangOpts().ObjC && NextToken().isObjCAtKeyword(tok::objc_defs))
   Diag(Tok, diag::err_at_defs_cxx);
@@ -2702,7 +2704,7 @@ Parser::ParseCXXClassMemberDeclaration(AccessSpecifier AS,
   bool MalformedTypeSpec = false;
   if (!TemplateInfo.Kind &&
   Tok.isOneOf(tok::identifier, tok::coloncolon, tok::kw___super)) {
-if (getLangOpts().CPlusPlus && TryAnnotateCXXScopeToken())
+if (TryAnnotateCXXScopeToken())
   MalformedTypeSpec = true;
 
 bool isAccessDecl;
diff --git a/clang/test/Parser/cxx-in-c.c b/clang/test/Parser/cxx-in-c.c
index f5fa39bd0cb99..bd304260571c4 100644
--- a/clang/test/Parser/cxx-in-c.c
+++ b/clang/test/Parser/cxx-in-c.c
@@ -3,3 +3,4 @@
 // PR9137
 void f0(int x) : {}; // expected-error{{expected function body after function 
declarator}}
 void f1(int x) try {}; // expected-error{{expected function body after 
function declarator}}
+::; // expected-error{{expected that double colon marker does not appear in c}}

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


[Lldb-commits] [lldb] [lldb] Disable new TestLocationListLookup when clang version is <= 11 (PR #75102)

2023-12-11 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Augusto Noronha (augusto2112)


Changes

The newly introduced LocationListLookupTestCase.test_loclist_expr test fails 
with older clangs.

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


1 Files Affected:

- (modified) 
lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py 
(+1) 


``diff
diff --git 
a/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py 
b/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
index ccee3bfde3f5d..aeb32fcea4c06 100644
--- 
a/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
+++ 
b/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
@@ -43,6 +43,7 @@ def test_loclist_frame_var(self):
 self.build()
 self.check_local_vars(self.launch(), check_expr=False)
 
+@skipIf(compiler="clang", compiler_version=['<=', '11.0'])
 @skipUnlessDarwin
 def test_loclist_expr(self):
 self.build()

``




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


[Lldb-commits] [lldb] [lldb] Disable new TestLocationListLookup when clang version is <= 11 (PR #75102)

2023-12-11 Thread Augusto Noronha via lldb-commits

https://github.com/augusto2112 created 
https://github.com/llvm/llvm-project/pull/75102

The newly introduced LocationListLookupTestCase.test_loclist_expr test fails 
with older clangs.

>From 0ec0f8ddf505ad30f8684e9452ebc4524f50a4b4 Mon Sep 17 00:00:00 2001
From: Augusto Noronha 
Date: Mon, 11 Dec 2023 13:29:25 -0800
Subject: [PATCH] [lldb] Disable new TestLocationListLookup when clang version
 is <= 11

The newly introduced LocationListLookupTestCase.test_loclist_expr test
fails with older clangs.
---
 .../location-list-lookup/TestLocationListLookup.py   | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py 
b/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
index ccee3bfde3f5d..aeb32fcea4c06 100644
--- 
a/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
+++ 
b/lldb/test/API/functionalities/location-list-lookup/TestLocationListLookup.py
@@ -43,6 +43,7 @@ def test_loclist_frame_var(self):
 self.build()
 self.check_local_vars(self.launch(), check_expr=False)
 
+@skipIf(compiler="clang", compiler_version=['<=', '11.0'])
 @skipUnlessDarwin
 def test_loclist_expr(self):
 self.build()

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


[Lldb-commits] [lldb] [lldb-dap] Implement command directives (PR #74808)

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

walter-erquinigo wrote:

> "error: one of your required 'attachCommands' failed, check the debug console 
> for details"

This is a key thing that I didn't consider in the beginning. I'm going to 
update this patch to only support `?`, and then I'll make another one for `!`, 
because I need to explore how to send visible notifications to the IDE.

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


[Lldb-commits] [lldb] [lldb-dap] Emit declarations along with variables (PR #74865)

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

walter-erquinigo wrote:

> Might be good idea to only add "declaration" if and only if we have both a 
> file and line at least?

I think it's better to emit it if there's at least one of them. We can leave it 
to the client the decision of what to do if only one of them is available.

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


[Lldb-commits] [lldb] [lldb-dap] Emit declarations along with variables (PR #74865)

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


@@ -1165,6 +1188,24 @@ llvm::json::Value CreateVariable(lldb::SBValue v, 
int64_t variablesReference,
   const char *evaluateName = evaluateStream.GetData();
   if (evaluateName && evaluateName[0])
 EmplaceSafeString(object, "evaluateName", std::string(evaluateName));
+
+  if (lldb::SBDeclaration decl = v.GetDeclaration(); decl.IsValid()) {
+llvm::json::Object decl_obj;
+if (lldb::SBFileSpec file = decl.GetFileSpec(); file.IsValid()) {
+  char path[PATH_MAX] = "";
+  if (file.GetPath(path, sizeof(path)) &&
+  lldb::SBFileSpec::ResolvePath(path, path, PATH_MAX)) {
+decl_obj.try_emplace("path", std::string(path));
+  }
+}
+
+if (int line = decl.GetLine())
+  decl_obj.try_emplace("line", line);
+if (int column = decl.GetColumn())
+  decl_obj.try_emplace("column", column);
+
+object.try_emplace("declaration", std::move(decl_obj));

walter-erquinigo wrote:

This one makes sense. I'll make that fix.

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


[Lldb-commits] [lldb] [lldb-dap] Emit declarations along with variables (PR #74865)

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

https://github.com/clayborg commented:

Might be good idea to only add "declaration" if and only if we have both a file 
and line at least?

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


[Lldb-commits] [lldb] [lldb-dap] Emit declarations along with variables (PR #74865)

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


@@ -1165,6 +1188,24 @@ llvm::json::Value CreateVariable(lldb::SBValue v, 
int64_t variablesReference,
   const char *evaluateName = evaluateStream.GetData();
   if (evaluateName && evaluateName[0])
 EmplaceSafeString(object, "evaluateName", std::string(evaluateName));
+
+  if (lldb::SBDeclaration decl = v.GetDeclaration(); decl.IsValid()) {
+llvm::json::Object decl_obj;
+if (lldb::SBFileSpec file = decl.GetFileSpec(); file.IsValid()) {
+  char path[PATH_MAX] = "";
+  if (file.GetPath(path, sizeof(path)) &&
+  lldb::SBFileSpec::ResolvePath(path, path, PATH_MAX)) {
+decl_obj.try_emplace("path", std::string(path));
+  }
+}
+
+if (int line = decl.GetLine())
+  decl_obj.try_emplace("line", line);
+if (int column = decl.GetColumn())
+  decl_obj.try_emplace("column", column);
+
+object.try_emplace("declaration", std::move(decl_obj));

clayborg wrote:

So above we might or might not get any of the info, do we want to only emplace 
this into "declaration" if we at least have both a valid path _and_ a valid 
line?

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


[Lldb-commits] [lldb] [lldb-dap] Emit declarations along with variables (PR #74865)

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

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


[Lldb-commits] [lldb] [lldb-dap] Emit declarations along with variables (PR #74865)

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

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


[Lldb-commits] [lldb] 0ea19bd - [lldb-dap] Emit declarations along with variables (#74865)

2023-12-11 Thread via lldb-commits

Author: Walter Erquinigo
Date: 2023-12-11T15:20:06-05:00
New Revision: 0ea19bdaf71dd3aaf7c0a6ef9a0930958c12

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

LOG: [lldb-dap] Emit declarations along with variables (#74865)

This is an extension to the protocol that emits the declaration
information along with the metadata of each variable. This can be used
by vscode extensions to implement, for example, a "goToDefinition"
action in the debug tab, or for showing the value of a variable right
next to where it's declared during a debug session.
As this is cheap, I'm not gating this information under any setting.

Added: 


Modified: 
lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py
lldb/tools/lldb-dap/JSONUtils.cpp

Removed: 




diff  --git a/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py 
b/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py
index d2a21ad3cd1d4..9b0755eea7d3e 100644
--- a/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py
+++ b/lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py
@@ -4,8 +4,8 @@
 
 import os
 
-import lldbdap_testcase
 import dap_server
+import lldbdap_testcase
 from lldbsuite.test import lldbutil
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
@@ -152,7 +152,13 @@ def do_test_scopes_variables_setVariable_evaluate(
 globals = self.dap_server.get_global_variables()
 buffer_children = make_buffer_verify_dict(0, 32)
 verify_locals = {
-"argc": {"equals": {"type": "int", "value": "1"}},
+"argc": {
+"equals": {"type": "int", "value": "1"},
+"declaration": {
+"equals": {"line": 12, "column": 14},
+"contains": {"path": ["lldb-dap", "variables", 
"main.cpp"]},
+},
+},
 "argv": {
 "equals": {"type": "const char **"},
 "startswith": {"value": "0x"},

diff  --git a/lldb/tools/lldb-dap/JSONUtils.cpp 
b/lldb/tools/lldb-dap/JSONUtils.cpp
index 62d7fa54e75f1..c8e5304ecec81 100644
--- a/lldb/tools/lldb-dap/JSONUtils.cpp
+++ b/lldb/tools/lldb-dap/JSONUtils.cpp
@@ -1103,6 +1103,29 @@ std::string 
CreateUniqueVariableNameForDisplay(lldb::SBValue v,
 //   can use this optional information to present the
 //   children in a paged UI and fetch them in chunks."
 // }
+// "declaration": {
+//   "type": "object | undefined",
+//   "description": "Extension to the protocol that indicates the source
+//   location where the variable was declared. This value
+//   might not be present if no declaration is available.",
+//   "properties": {
+// "path": {
+//   "type": "string | undefined",
+//   "description": "The source file path where the variable was
+//   declared."
+// },
+// "line": {
+//   "type": "number | undefined",
+//   "description": "The 1-indexed source line where the variable was
+//  declared."
+// },
+// "column": {
+//   "type": "number | undefined",
+//   "description": "The 1-indexed source column where the variable was
+//  declared."
+// }
+//   }
+// }
 //   },
 //   "required": [ "name", "value", "variablesReference" ]
 // }
@@ -1167,6 +1190,24 @@ llvm::json::Value CreateVariable(lldb::SBValue v, 
int64_t variablesReference,
   const char *evaluateName = evaluateStream.GetData();
   if (evaluateName && evaluateName[0])
 EmplaceSafeString(object, "evaluateName", std::string(evaluateName));
+
+  if (lldb::SBDeclaration decl = v.GetDeclaration(); decl.IsValid()) {
+llvm::json::Object decl_obj;
+if (lldb::SBFileSpec file = decl.GetFileSpec(); file.IsValid()) {
+  char path[PATH_MAX] = "";
+  if (file.GetPath(path, sizeof(path)) &&
+  lldb::SBFileSpec::ResolvePath(path, path, PATH_MAX)) {
+decl_obj.try_emplace("path", std::string(path));
+  }
+}
+
+if (int line = decl.GetLine())
+  decl_obj.try_emplace("line", line);
+if (int column = decl.GetColumn())
+  decl_obj.try_emplace("column", column);
+
+object.try_emplace("declaration", std::move(decl_obj));
+  }
   return llvm::json::Value(std::move(object));
 }
 



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


[Lldb-commits] [lldb] [lldb-dap] Implement command directives (PR #74808)

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

clayborg wrote:

> @clayborg , I actually insist on aborting on failure for this feature. You 
> mention:
> 
> > It would be nice if the RunLLDBCommands function could take an extra bool 
> > _error that clients could check after running when needed to decide 
> > what to do if this is set to true due to any ! prefixed commands failing.
> 
> That would imply that some commands would have a specific behavior upon a 
> failed ! command, and other commands would have a different behavior. That 
> makes this feature a bit hard to use by actual users, as it wouldn't have a 
> consistent behavior, unlike ? commands.
> 
> What I wanted to achieve with ! was to have a way for users to tell the 
> lldb-dap: hey, this command is critical for my flow, abort if it fails. 
> Having a mild behavior instead of aborting kind of defeats the purpose of 
> this feature.

Yeah but does aborting tell the client anything useful? Lets say we are in the 
middle of doing an `attach` packet and an attach command fails, what do we see 
in the IDE? Probably something like "DAP crashed" and the user is going to need 
to know that they should check the debug console? I would much rather have the 
`attach` packet return an erorr that says "error: one of your required 
'attachCommands' failed, check the debug console for details", or during 
`launch` seeing "error: one of your required 'launchCommands' failed, check the 
debug console for details".

If you look at how `request_attach` and `request_lauch` are configured, they do 
most of the `g_dap.RunXXXCommands` and the both packets allow us to return an 
error that would make it much more clear what went wrong.

There are a few other areas that run commands like `SendTerminatedEvent()` that 
calls `g_dap.RunTerminateCommands();` and `SendThreadStoppedEvent()` that can 
call `g_dap.RunStopCommands();`, but other than that they are mostly in 
`launch` or `attach`. 

So I don't see how just crashing the DAP helps in any way when we can easily 
return a very clear error to either `launch` or `attach` and the user will know 
exactly what went wrong. 

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


[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

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


@@ -2225,7 +2225,8 @@ void ObjectFileMachO::ParseSymtab(Symtab ) {
   const char *file_name = file.GetFilename().AsCString("");
   LLDB_SCOPED_TIMERF("ObjectFileMachO::ParseSymtab () module = %s", file_name);
   LLDB_LOG(log, "Parsing symbol table for {0}", file_name);
-  Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name));
+  Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name),
+Progress::ProgressReportType::eAggregateProgressReport);

clayborg wrote:

And if we want to allow different platforms to say what is useful and what 
isn't we can provide commands to control these if needed. We can have an 
internal enumeration for the categories if needed, or we can add a string as 
the category to help say "please disable all symbol table parsing" progress 
dialogs.

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


[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

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

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


[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

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


@@ -2225,7 +2225,8 @@ void ObjectFileMachO::ParseSymtab(Symtab ) {
   const char *file_name = file.GetFilename().AsCString("");
   LLDB_SCOPED_TIMERF("ObjectFileMachO::ParseSymtab () module = %s", file_name);
   LLDB_LOG(log, "Parsing symbol table for {0}", file_name);
-  Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name));
+  Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name),
+Progress::ProgressReportType::eAggregateProgressReport);

clayborg wrote:

> @clayborg I understand your point but how would a category string be 
> different from filtering out the progress events based on the progress title 
> string (or parts of it) ?

It would stop clients from having to add logic to try and look for common 
substrings, but other than that not much different. It would allow progress 
titles to vary quite a bit more, but they don't right now.

> I see how certain progress reports could be relevant to linux where we 
> wouldn't want to surface it on macOS. The reason we came up with this 
> approach is precisely because we prefer having LLDB tell its clients what 
> progress should be displayed, rather than having the filtering logic be done 
> in the client.

Not sure I follow? Are you saying if `is_aggregate == true` that we are letting 
users know they should ignore these progress reports? And we are setting to 
true for all progress reports except for Swift and a few other rarely used ones?

> May we could keep a list of blacklisted progress title / categories for every 
> platform and either submit progress reports if they're not in that list or 
> have an SBAPI to fetch the list of blacklisted progresses from the client ? 
> What do you think about this ?

One ideas is if we have categories, we could have settings that could control 
if the progress reports for a given category should be displayed. Those could 
easily be set after initializing a debugger object.

> (also cc @JDevlieghere since he will probably have some opinions about this).

Sounds good

The entire idea of the progress dialogs is to provide insight for when the 
debugger seems to be stalled, but it is actually doing work. If we have any 
progress items that are not useful, we should remove them. But parsing symbol 
tables, even on Mac, can sometimes take a few seconds on larger binaries, so I 
find this useful when running LLDB from the command line. Indexing DWARF is a 
huge time sync for really large projects which often can take many minutes to 
complete and when I load them on the command line, seeing the progress in the 
terminal is very useful.

So a few things that seem to stand out to me:
- Darwin will never see the `Manually indexing DWARF for ` progress 
dialogs, and these are needed and should always be displayed.
- Darwin does see the `Parsing symbol table for  progress dialogs, but 
many are fast and probably are part of the problem you want to fix?
- "Loading Apple DWARF index for " has no real work being done here, just 
initializing a memory buffer, seems like it should probably be removed to cut 
down on the noise?
- "Loading DWARF5 index for " is the same kind of thing for both Darwin 
and linux (no real work to be done, the accelerator tables are "ready to use")
- "Locating external symbol file for " seems useful if the download can 
take a while

I don't see any other uses in the upstream LLDB sources.

But my main point is we make Progress dialogs for a reason and we should make 
sure they are useful and that everyone wants them. 


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


[Lldb-commits] [lldb] 07ed325 - [lldb-dap] Include [opt] in the frame name only if a custom frame format is not specified. (#74861)

2023-12-11 Thread via lldb-commits

Author: Walter Erquinigo
Date: 2023-12-11T14:46:25-05:00
New Revision: 07ed3258d0b38bdfd60c203c23a59c8ce8def914

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

LOG: [lldb-dap] Include [opt] in the frame name only if a custom frame format 
is not specified. (#74861)

Currently there's an include in which `[opt]` might be emitted twice if
the frame format also asks for it. As a trivial fix, we should manually
emit `[opt]` only if a custom frame format is not specified.

Added: 


Modified: 
lldb/tools/lldb-dap/JSONUtils.cpp

Removed: 




diff  --git a/lldb/tools/lldb-dap/JSONUtils.cpp 
b/lldb/tools/lldb-dap/JSONUtils.cpp
index 3a63046d9a888..62d7fa54e75f1 100644
--- a/lldb/tools/lldb-dap/JSONUtils.cpp
+++ b/lldb/tools/lldb-dap/JSONUtils.cpp
@@ -804,9 +804,11 @@ llvm::json::Value CreateStackFrame(lldb::SBFrame ) {
 llvm::raw_string_ostream os(frame_name);
 os << llvm::format_hex(frame.GetPC(), 18);
   }
-  bool is_optimized = frame.GetFunction().GetIsOptimized();
-  if (is_optimized)
+
+  // We only include `[opt]` if a custom frame format is not specified.
+  if (!g_dap.frame_format && frame.GetFunction().GetIsOptimized())
 frame_name += " [opt]";
+
   EmplaceSafeString(object, "name", frame_name);
 
   auto source = CreateSource(frame);



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


[Lldb-commits] [lldb] [lldb-dap] Include [opt] in the frame name only if a custom frame format is not specified. (PR #74861)

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

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


[Lldb-commits] [lldb] lldb: add support for thread names on Windows (PR #74731)

2023-12-11 Thread Alex Langford via lldb-commits

bulbazord wrote:

@compnerd Perhaps you can take a look at this one? Not sure who does Windows 
work on LLDB these days.

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits

Michael137 wrote:

BTW, lets prefix the commit with `[lldb]` before merging

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


[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-11 Thread Med Ismail Bennani via lldb-commits


@@ -2225,7 +2225,8 @@ void ObjectFileMachO::ParseSymtab(Symtab ) {
   const char *file_name = file.GetFilename().AsCString("");
   LLDB_SCOPED_TIMERF("ObjectFileMachO::ParseSymtab () module = %s", file_name);
   LLDB_LOG(log, "Parsing symbol table for {0}", file_name);
-  Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name));
+  Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name),
+Progress::ProgressReportType::eAggregateProgressReport);

medismailben wrote:

@clayborg I understand your point but how would a category string be different 
from filtering out the progress events based on the progress title string (or 
parts of it) ?

I see how certain progress reports could be relevant to linux where we wouldn't 
want to surface it on macOS. The reason we came up with this approach is 
precisely because we prefer having LLDB tell its clients what progress should 
be displayed, rather than having the filtering logic be done in the client.

May we could keep a list of blacklisted progress title / categories for every 
platform and either submit progress reports if they're not in that list or have 
an SBAPI to fetch the list of blacklisted progresses from the client ? What do 
you think about this ?

(also cc @JDevlieghere since he will probably have some opinions about this).

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -122,6 +106,9 @@ class TypeSystem : public PluginInterface,
   virtual CompilerType DeclGetFunctionArgumentType(void *opaque_decl,
size_t arg_idx);
 
+  virtual std::vector
+  DeclGetCompilerContext(void *opaque_decl);

Michael137 wrote:

yea makes sense, looks like that's what all the other TypeSystem APIs do too

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -64,6 +64,125 @@ bool 
lldb_private::contextMatches(llvm::ArrayRef context_chain,
   return true;
 }
 
+static CompilerContextKind ConvertTypeClass(lldb::TypeClass type_class) {
+  if (type_class == eTypeClassAny)
+return CompilerContextKind::AnyType;
+  uint16_t result = 0;
+  if (type_class & lldb::eTypeClassClass)
+result |= (uint16_t)CompilerContextKind::Class;
+  if (type_class & lldb::eTypeClassStruct)
+result |= (uint16_t)CompilerContextKind::Struct;
+  if (type_class & lldb::eTypeClassUnion)
+result |= (uint16_t)CompilerContextKind::Union;
+  if (type_class & lldb::eTypeClassEnumeration)
+result |= (uint16_t)CompilerContextKind::Enum;
+  if (type_class & lldb::eTypeClassFunction)
+result |= (uint16_t)CompilerContextKind::Function;
+  if (type_class & lldb::eTypeClassTypedef)
+result |= (uint16_t)CompilerContextKind::Typedef;
+  return (CompilerContextKind)result;
+}
+
+TypeQuery::TypeQuery(llvm::StringRef name, TypeQueryOptions options)
+: m_options(options) {
+  llvm::StringRef scope, basename;
+  lldb::TypeClass type_class = lldb::eTypeClassAny;
+  if (Type::GetTypeScopeAndBasename(name, scope, basename, type_class)) {
+if (scope.consume_front("::"))
+  m_options |= e_exact_match;
+if (!scope.empty()) {
+  std::pair scope_pair =
+  scope.split("::");
+  while (!scope_pair.second.empty()) {
+m_context.push_back({CompilerContextKind::AnyDeclContext,
+ ConstString(scope_pair.first.str())});
+scope_pair = scope_pair.second.split("::");
+  }
+  m_context.push_back({CompilerContextKind::AnyDeclContext,
+   ConstString(scope_pair.first.str())});
+}
+m_context.push_back(
+{ConvertTypeClass(type_class), ConstString(basename.str())});
+  } else {
+m_context.push_back(
+{CompilerContextKind::AnyType, ConstString(name.str())});
+  }
+}
+
+TypeQuery::TypeQuery(const CompilerDeclContext _ctx,
+ ConstString type_basename, TypeQueryOptions options)
+: m_options(options) {
+  // Always use an exact match if we are looking for a type in compiler 
context.
+  m_options |= e_exact_match;
+  m_context = decl_ctx.GetCompilerContext();
+  m_context.push_back({CompilerContextKind::AnyType, type_basename});
+}
+
+TypeQuery::TypeQuery(
+const llvm::ArrayRef ,
+TypeQueryOptions options)
+: m_context(context), m_options(options) {
+  // Always use an exact match if we are looking for a type in compiler 
context.
+  m_options |= e_exact_match;
+}
+
+TypeQuery::TypeQuery(const CompilerDecl , TypeQueryOptions options)
+: m_options(options) {
+  // Always for an exact match if we are looking for a type using a 
declaration.
+  m_options |= e_exact_match;
+  m_context = decl.GetCompilerContext();
+}
+
+ConstString TypeQuery::GetTypeBasename() const {
+  if (m_context.empty())
+return ConstString();
+  return m_context.back().name;
+}
+
+void TypeQuery::AddLanguage(LanguageType language) {
+  if (!m_languages)
+m_languages = LanguageSet();
+  m_languages->Insert(language);
+}
+
+bool TypeQuery::ContextMatches(
+llvm::ArrayRef context_chain) const {
+  if (GetExactMatch() || context_chain.size() == m_context.size())
+return ::contextMatches(context_chain, m_context);
+
+  // We don't have an exact match, we need to bottom m_context.size() items to
+  // match for a successful lookup.
+  if (context_chain.size() < m_context.size())
+return false; // Not enough items in context_chain to allow for a match.
+
+  size_t compare_count = context_chain.size() - m_context.size();
+  return ::contextMatches(
+  llvm::ArrayRef(context_chain.data() + compare_count,
+  m_context.size()),
+  m_context);
+}
+
+bool TypeQuery::LanguageMatches(lldb::LanguageType language) const {
+  // If we have no language filterm language always matches.
+  if (!m_languages.has_value())
+return true;
+  return (*m_languages)[language];
+}
+
+bool TypeResults::AlreadySearched(lldb_private::SymbolFile *sym_file) {
+  return !m_searched_symbol_files.insert(sym_file).second;

Michael137 wrote:

Ah makes sense

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

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


@@ -64,6 +64,125 @@ bool 
lldb_private::contextMatches(llvm::ArrayRef context_chain,
   return true;
 }
 
+static CompilerContextKind ConvertTypeClass(lldb::TypeClass type_class) {
+  if (type_class == eTypeClassAny)
+return CompilerContextKind::AnyType;
+  uint16_t result = 0;
+  if (type_class & lldb::eTypeClassClass)
+result |= (uint16_t)CompilerContextKind::Class;
+  if (type_class & lldb::eTypeClassStruct)
+result |= (uint16_t)CompilerContextKind::Struct;
+  if (type_class & lldb::eTypeClassUnion)
+result |= (uint16_t)CompilerContextKind::Union;
+  if (type_class & lldb::eTypeClassEnumeration)
+result |= (uint16_t)CompilerContextKind::Enum;
+  if (type_class & lldb::eTypeClassFunction)
+result |= (uint16_t)CompilerContextKind::Function;
+  if (type_class & lldb::eTypeClassTypedef)
+result |= (uint16_t)CompilerContextKind::Typedef;
+  return (CompilerContextKind)result;
+}
+
+TypeQuery::TypeQuery(llvm::StringRef name, TypeQueryOptions options)
+: m_options(options) {
+  llvm::StringRef scope, basename;
+  lldb::TypeClass type_class = lldb::eTypeClassAny;
+  if (Type::GetTypeScopeAndBasename(name, scope, basename, type_class)) {
+if (scope.consume_front("::"))
+  m_options |= e_exact_match;
+if (!scope.empty()) {
+  std::pair scope_pair =
+  scope.split("::");
+  while (!scope_pair.second.empty()) {
+m_context.push_back({CompilerContextKind::AnyDeclContext,
+ ConstString(scope_pair.first.str())});
+scope_pair = scope_pair.second.split("::");
+  }
+  m_context.push_back({CompilerContextKind::AnyDeclContext,
+   ConstString(scope_pair.first.str())});
+}
+m_context.push_back(
+{ConvertTypeClass(type_class), ConstString(basename.str())});
+  } else {
+m_context.push_back(
+{CompilerContextKind::AnyType, ConstString(name.str())});
+  }
+}
+
+TypeQuery::TypeQuery(const CompilerDeclContext _ctx,
+ ConstString type_basename, TypeQueryOptions options)
+: m_options(options) {
+  // Always use an exact match if we are looking for a type in compiler 
context.
+  m_options |= e_exact_match;
+  m_context = decl_ctx.GetCompilerContext();
+  m_context.push_back({CompilerContextKind::AnyType, type_basename});
+}
+
+TypeQuery::TypeQuery(
+const llvm::ArrayRef ,
+TypeQueryOptions options)
+: m_context(context), m_options(options) {
+  // Always use an exact match if we are looking for a type in compiler 
context.
+  m_options |= e_exact_match;
+}
+
+TypeQuery::TypeQuery(const CompilerDecl , TypeQueryOptions options)
+: m_options(options) {
+  // Always for an exact match if we are looking for a type using a 
declaration.
+  m_options |= e_exact_match;
+  m_context = decl.GetCompilerContext();
+}
+
+ConstString TypeQuery::GetTypeBasename() const {
+  if (m_context.empty())
+return ConstString();
+  return m_context.back().name;
+}
+
+void TypeQuery::AddLanguage(LanguageType language) {
+  if (!m_languages)
+m_languages = LanguageSet();
+  m_languages->Insert(language);
+}
+
+bool TypeQuery::ContextMatches(
+llvm::ArrayRef context_chain) const {
+  if (GetExactMatch() || context_chain.size() == m_context.size())
+return ::contextMatches(context_chain, m_context);
+
+  // We don't have an exact match, we need to bottom m_context.size() items to
+  // match for a successful lookup.
+  if (context_chain.size() < m_context.size())
+return false; // Not enough items in context_chain to allow for a match.
+
+  size_t compare_count = context_chain.size() - m_context.size();
+  return ::contextMatches(
+  llvm::ArrayRef(context_chain.data() + compare_count,
+  m_context.size()),
+  m_context);
+}
+
+bool TypeQuery::LanguageMatches(lldb::LanguageType language) const {
+  // If we have no language filterm language always matches.
+  if (!m_languages.has_value())
+return true;
+  return (*m_languages)[language];
+}
+
+bool TypeResults::AlreadySearched(lldb_private::SymbolFile *sym_file) {
+  return !m_searched_symbol_files.insert(sym_file).second;

clayborg wrote:

We actually want to try and insert it as this function is called as something 
that puts the symbol file into the map and returns `false` if it wasn't in the 
set. Or it tries to add it and returns `true` if it was alraedy in there. I 
have modified the header documentation to make this more clear.

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


[Lldb-commits] [lldb] [llvm] [libc] [libcxx] [flang] [compiler-rt] [mlir] [clang-tools-extra] [openmp] [clang] [libc++][span] P2821R5: span.at() (PR #74994)

2023-12-11 Thread Hristo Hristov via lldb-commits


@@ -343,6 +345,15 @@ public:
 return __data_[__idx];
 }
 
+#  if _LIBCPP_STD_VER >= 26
+_LIBCPP_HIDE_FROM_ABI constexpr reference at(size_type __index) const {
+  if (__index >= size()) {

H-G-Hristov wrote:

Done! Sorry I missed that.

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

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


@@ -12,33 +12,32 @@ class UniqueTypesTestCase4(TestBase):
 def do_test(self, debug_flags):
 """Test that we display the correct template instantiation."""
 self.build(dictionary=debug_flags)
+exe = self.getBuildArtifact("a.out")
+print(exe)
 lldbutil.run_to_source_breakpoint(
 self, "// Set breakpoint here", lldb.SBFileSpec("main.cpp")
 )
 # FIXME: these should successfully print the values
 self.expect(
-"expression ns::Foo::value", substrs=["no member named"], 
error=True
+"print ns::Foo::value", substrs=["no template named 'Foo' 
in namespace 'ns'"], error=True

clayborg wrote:

switched them back to use `expression`

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

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


@@ -12,33 +12,32 @@ class UniqueTypesTestCase4(TestBase):
 def do_test(self, debug_flags):
 """Test that we display the correct template instantiation."""
 self.build(dictionary=debug_flags)
+exe = self.getBuildArtifact("a.out")
+print(exe)

clayborg wrote:

yes, I will remove

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

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


@@ -1446,23 +1446,23 @@ void SymbolFilePDB::AddSymbols(lldb_private::Symtab 
) {
   symtab.Finalize();
 }
 
-void SymbolFilePDB::FindTypes(
-lldb_private::ConstString name, const CompilerDeclContext _decl_ctx,
-uint32_t max_matches,
-llvm::DenseSet _symbol_files,
-lldb_private::TypeMap ) {
-  std::lock_guard guard(GetModuleMutex());
-  if (!name)
-return;
-  if (!DeclContextMatchesThisSymbolFile(parent_decl_ctx))
-return;
-
-  searched_symbol_files.clear();
-  searched_symbol_files.insert(this);
-
-  // There is an assumption 'name' is not a regex
-  FindTypesByName(name.GetStringRef(), parent_decl_ctx, max_matches, types);
-}
+// void SymbolFilePDB::FindTypes(
+// lldb_private::ConstString name, const CompilerDeclContext
+// _decl_ctx, uint32_t max_matches,
+// llvm::DenseSet _symbol_files,
+// lldb_private::TypeMap ) {
+//   std::lock_guard guard(GetModuleMutex());
+//   if (!name)
+// return;
+//   if (!DeclContextMatchesThisSymbolFile(parent_decl_ctx))
+// return;
+
+//   searched_symbol_files.clear();
+//   searched_symbol_files.insert(this);
+
+//   // There is an assumption 'name' is not a regex
+//   FindTypesByName(name.GetStringRef(), parent_decl_ctx, max_matches, types);
+// }

clayborg wrote:

yes!

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

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


@@ -122,6 +106,9 @@ class TypeSystem : public PluginInterface,
   virtual CompilerType DeclGetFunctionArgumentType(void *opaque_decl,
size_t arg_idx);
 
+  virtual std::vector
+  DeclGetCompilerContext(void *opaque_decl);

clayborg wrote:

I would rather not put any limitations on TypeSystem plug-ins in case they can 
be more efficient if they can put off parsing information about a type until 
accessors are called on the `Decl` objects.

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

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


@@ -146,6 +133,9 @@ class TypeSystem : public PluginInterface,
   virtual CompilerDeclContext
   GetCompilerDeclContextForType(const CompilerType );
 
+  virtual std::vector
+  DeclContextGetCompilerContext(void *opaque_decl_ctx);

clayborg wrote:

I would rather not put any limitations on TypeSystem plug-ins in case they can 
be more efficient if they can put off parsing information about a type until 
accessors are called on the `DeclContext` objects.

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

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


@@ -1696,16 +1696,16 @@ static size_t LookupTypeInModule(Target *target,
  CommandInterpreter , Stream ,
  Module *module, const char *name_cstr,
  bool name_is_regex) {
-  TypeList type_list;
   if (module && name_cstr && name_cstr[0]) {
-const uint32_t max_num_matches = UINT32_MAX;
-bool name_is_fully_qualified = false;
-
-ConstString name(name_cstr);
-llvm::DenseSet searched_symbol_files;
-module->FindTypes(name, name_is_fully_qualified, max_num_matches,
-  searched_symbol_files, type_list);
+TypeQuery query(name_cstr);
+TypeResults results;
+module->FindTypes(query, results);
 
+TypeList type_list;
+SymbolContext sc;
+if (module)
+  sc.module_sp = module->shared_from_this();
+sc.SortTypeList(results.GetTypeMap(), type_list);

clayborg wrote:

Will do

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

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


@@ -1859,17 +1851,11 @@ lldb::SBTypeList SBTarget::FindTypes(const char 
*typename_cstr) {
   if (typename_cstr && typename_cstr[0] && target_sp) {
 ModuleList  = target_sp->GetImages();
 ConstString const_typename(typename_cstr);
-bool exact_match = false;
-TypeList type_list;
-llvm::DenseSet searched_symbol_files;
-images.FindTypes(nullptr, const_typename, exact_match, UINT32_MAX,
- searched_symbol_files, type_list);
-
-for (size_t idx = 0; idx < type_list.GetSize(); idx++) {
-  TypeSP type_sp(type_list.GetTypeAtIndex(idx));
-  if (type_sp)
-sb_type_list.Append(SBType(type_sp));
-}
+TypeQuery query(typename_cstr);
+TypeResults results;
+images.FindTypes(nullptr, query, results);
+for (const TypeSP _sp : results.GetTypeMap().Types())

clayborg wrote:

I will change `TypeResults::InsertUnique(...)` to not add any invalid TypeSP 
objects.

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


[Lldb-commits] [compiler-rt] [flang] [clang-tools-extra] [llvm] [libcxx] [clang] [mlir] [lldb] [libc] [openmp] [libc++][span] P2821R5: span.at() (PR #74994)

2023-12-11 Thread Hristo Hristov via lldb-commits

https://github.com/H-G-Hristov updated 
https://github.com/llvm/llvm-project/pull/74994

>From 6e26ca239c49e1b7d9ab72217db7339e92df163f Mon Sep 17 00:00:00 2001
From: Zingam 
Date: Sun, 10 Dec 2023 14:16:02 +0200
Subject: [PATCH 01/12] [libc++][span] P2821R5: span.at()

---
 libcxx/include/span   |  30 +++
 .../views/views.span/span.elem/at.pass.cpp| 246 ++
 .../views.span/span.elem/op_idx.pass.cpp  |   1 -
 3 files changed, 276 insertions(+), 1 deletion(-)
 create mode 100644 
libcxx/test/std/containers/views/views.span/span.elem/at.pass.cpp

diff --git a/libcxx/include/span b/libcxx/include/span
index 69b0a2875e26cc..b015d7cf1c15b6 100644
--- a/libcxx/include/span
+++ b/libcxx/include/span
@@ -92,6 +92,7 @@ public:
 
 // [span.elem], span element access
 constexpr reference operator[](size_type idx) const;
+constexpr reference at(size_type idx) const; // since C++26
 constexpr reference front() const;
 constexpr reference back() const;
 constexpr pointer data() const noexcept;
@@ -146,6 +147,9 @@ template
 #include <__utility/forward.h>
 #include // for array
 #include   // for byte
+#if _LIBCPP_STD_VER >= 26
+#  include 
+#endif
 #include 
 
 // standard-mandated includes
@@ -343,6 +347,15 @@ public:
 return __data_[__idx];
 }
 
+#  if _LIBCPP_STD_VER >= 26
+_LIBCPP_HIDE_FROM_ABI constexpr reference at(size_type __idx) const {
+  if (__idx >= size()) {
+__throw_out_of_range();
+  }
+  return *(data() + __idx);
+}
+#  endif
+
 _LIBCPP_INLINE_VISIBILITY constexpr reference front() const noexcept
 {
 _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(!empty(), "span::front() on 
empty span");
@@ -383,6 +396,10 @@ public:
 
 private:
 pointer__data_;
+
+#  if _LIBCPP_STD_VER >= 26
+_LIBCPP_NORETURN _LIBCPP_HIDE_FROM_ABI void __throw_out_of_range() const { 
std::__throw_out_of_range("span"); }
+#  endif
 };
 
 
@@ -510,6 +527,15 @@ public:
 return __data_[__idx];
 }
 
+#  if _LIBCPP_STD_VER >= 26
+_LIBCPP_HIDE_FROM_ABI constexpr reference at(size_type __idx) const {
+  if (__idx >= size()) {
+__throw_out_of_range();
+  }
+  return *(data() + __idx);
+}
+#  endif
+
 _LIBCPP_INLINE_VISIBILITY constexpr reference front() const noexcept
 {
 _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(!empty(), "span::front() on 
empty span");
@@ -552,6 +578,10 @@ public:
 private:
 pointer   __data_;
 size_type __size_;
+
+#  if _LIBCPP_STD_VER >= 26
+_LIBCPP_NORETURN _LIBCPP_HIDE_FROM_ABI void __throw_out_of_range() const { 
std::__throw_out_of_range("span"); }
+#  endif
 };
 
 template 
diff --git a/libcxx/test/std/containers/views/views.span/span.elem/at.pass.cpp 
b/libcxx/test/std/containers/views/views.span/span.elem/at.pass.cpp
new file mode 100644
index 00..2a9ce2baeec1a5
--- /dev/null
+++ b/libcxx/test/std/containers/views/views.span/span.elem/at.pass.cpp
@@ -0,0 +1,246 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+// UNSUPPORTED: c++03, c++11, c++14, c++17, c++20, c++23
+
+// 
+
+// constexpr reference at(size_type idx) const; // since C++26
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "test_macros.h"
+
+// template 
+// constexpr bool testConstexprSpan(Span sp, std::size_t idx)
+// {
+// LIBCPP_ASSERT(noexcept(sp[idx]));
+
+// typename Span::reference r1 = sp[idx];
+// typename Span::reference r2 = *(sp.data() + idx);
+
+// return r1 == r2;
+// }
+
+// template 
+// void testRuntimeSpan(Span sp, std::size_t idx)
+// {
+// LIBCPP_ASSERT(noexcept(sp[idx]));
+
+// typename Span::reference r1 = sp[idx];
+// typename Span::reference r2 = *(sp.data() + idx);
+
+// assert(r1 == r2);
+// }
+
+// struct A{};
+// constexpr int iArr1[] = { 0,  1,  2,  3,  4,  5,  6,  7,  8,  9};
+//   int iArr2[] = {10, 11, 12, 13, 14, 15, 16, 17, 18, 19};
+
+// int main(int, char**)
+// {
+// static_assert(testConstexprSpan(std::span(iArr1, 1), 0), "");
+
+// static_assert(testConstexprSpan(std::span(iArr1, 2), 0), "");
+// static_assert(testConstexprSpan(std::span(iArr1, 2), 1), "");
+
+// static_assert(testConstexprSpan(std::span(iArr1, 3), 0), "");
+// static_assert(testConstexprSpan(std::span(iArr1, 3), 1), "");
+// static_assert(testConstexprSpan(std::span(iArr1, 3), 2), "");
+
+// static_assert(testConstexprSpan(std::span(iArr1, 4), 0), "");
+// static_assert(testConstexprSpan(std::span(iArr1, 4), 1), "");
+// static_assert(testConstexprSpan(std::span(iArr1, 4), 2), "");
+// 

[Lldb-commits] [lldb] [lldb-dap] Emit declarations along with variables (PR #74865)

2023-12-11 Thread Alex Langford via lldb-commits

https://github.com/bulbazord approved this pull request.


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


[Lldb-commits] [lldb] [lldb-dap] Emit declarations along with variables (PR #74865)

2023-12-11 Thread Alex Langford via lldb-commits

bulbazord wrote:

> > Is this extension to the protocol documented anywhere I can see? Or is this 
> > an ad-hoc thing? I think it would be useful to write down somewhere other 
> > than a commit message (in docs, comments, or otherwise) that this is an 
> > extension.
> 
> @bulbazord , it's an ad hoc thing. And I actually documented it in the 
> description of this field above the function :)

Oh! So you did, I see, in the `description` field. LGTM, thanks!

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


[Lldb-commits] [lldb] [lldb-dap] Include [opt] in the frame name only if a custom frame format is not specified. (PR #74861)

2023-12-11 Thread Alex Langford via lldb-commits

bulbazord wrote:

> `{${function.is-optimized} [opt]}` is how is already is and can be done with 
> frame formats, so I agree with this patch that if the user customizes it, 
> they have complete control and we shouldn't add anything. Does everyone else 
> agree?

I think I agree with this in principle -- this will give users complete control 
over the format of their frame, like frame formats were made to do. This change 
is breaking in the sense that folks who forgot to put `is-optimized` or is 
using a frame format they did not create (without `is-optimized`) will no 
longer know that they're debugging optimized code. I think this an acceptable 
trade-off.

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


[Lldb-commits] [lldb] [lldb-dap] Emit declarations along with variables (PR #74865)

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

walter-erquinigo wrote:

> Is this extension to the protocol documented anywhere I can see? Or is this 
> an ad-hoc thing? I think it would be useful to write down somewhere other 
> than a commit message (in docs, comments, or otherwise) that this is an 
> extension.

@bulbazord , it's an ad hoc thing. And I actually documented it in the 
description of this field above the function :)

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


[Lldb-commits] [lldb] [llvm] [libc] [libcxx] [flang] [compiler-rt] [mlir] [clang-tools-extra] [openmp] [clang] [libc++][span] P2821R5: span.at() (PR #74994)

2023-12-11 Thread Hristo Hristov via lldb-commits

https://github.com/H-G-Hristov updated 
https://github.com/llvm/llvm-project/pull/74994

>From 6e26ca239c49e1b7d9ab72217db7339e92df163f Mon Sep 17 00:00:00 2001
From: Zingam 
Date: Sun, 10 Dec 2023 14:16:02 +0200
Subject: [PATCH 01/11] [libc++][span] P2821R5: span.at()

---
 libcxx/include/span   |  30 +++
 .../views/views.span/span.elem/at.pass.cpp| 246 ++
 .../views.span/span.elem/op_idx.pass.cpp  |   1 -
 3 files changed, 276 insertions(+), 1 deletion(-)
 create mode 100644 
libcxx/test/std/containers/views/views.span/span.elem/at.pass.cpp

diff --git a/libcxx/include/span b/libcxx/include/span
index 69b0a2875e26cc..b015d7cf1c15b6 100644
--- a/libcxx/include/span
+++ b/libcxx/include/span
@@ -92,6 +92,7 @@ public:
 
 // [span.elem], span element access
 constexpr reference operator[](size_type idx) const;
+constexpr reference at(size_type idx) const; // since C++26
 constexpr reference front() const;
 constexpr reference back() const;
 constexpr pointer data() const noexcept;
@@ -146,6 +147,9 @@ template
 #include <__utility/forward.h>
 #include // for array
 #include   // for byte
+#if _LIBCPP_STD_VER >= 26
+#  include 
+#endif
 #include 
 
 // standard-mandated includes
@@ -343,6 +347,15 @@ public:
 return __data_[__idx];
 }
 
+#  if _LIBCPP_STD_VER >= 26
+_LIBCPP_HIDE_FROM_ABI constexpr reference at(size_type __idx) const {
+  if (__idx >= size()) {
+__throw_out_of_range();
+  }
+  return *(data() + __idx);
+}
+#  endif
+
 _LIBCPP_INLINE_VISIBILITY constexpr reference front() const noexcept
 {
 _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(!empty(), "span::front() on 
empty span");
@@ -383,6 +396,10 @@ public:
 
 private:
 pointer__data_;
+
+#  if _LIBCPP_STD_VER >= 26
+_LIBCPP_NORETURN _LIBCPP_HIDE_FROM_ABI void __throw_out_of_range() const { 
std::__throw_out_of_range("span"); }
+#  endif
 };
 
 
@@ -510,6 +527,15 @@ public:
 return __data_[__idx];
 }
 
+#  if _LIBCPP_STD_VER >= 26
+_LIBCPP_HIDE_FROM_ABI constexpr reference at(size_type __idx) const {
+  if (__idx >= size()) {
+__throw_out_of_range();
+  }
+  return *(data() + __idx);
+}
+#  endif
+
 _LIBCPP_INLINE_VISIBILITY constexpr reference front() const noexcept
 {
 _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(!empty(), "span::front() on 
empty span");
@@ -552,6 +578,10 @@ public:
 private:
 pointer   __data_;
 size_type __size_;
+
+#  if _LIBCPP_STD_VER >= 26
+_LIBCPP_NORETURN _LIBCPP_HIDE_FROM_ABI void __throw_out_of_range() const { 
std::__throw_out_of_range("span"); }
+#  endif
 };
 
 template 
diff --git a/libcxx/test/std/containers/views/views.span/span.elem/at.pass.cpp 
b/libcxx/test/std/containers/views/views.span/span.elem/at.pass.cpp
new file mode 100644
index 00..2a9ce2baeec1a5
--- /dev/null
+++ b/libcxx/test/std/containers/views/views.span/span.elem/at.pass.cpp
@@ -0,0 +1,246 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+// UNSUPPORTED: c++03, c++11, c++14, c++17, c++20, c++23
+
+// 
+
+// constexpr reference at(size_type idx) const; // since C++26
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "test_macros.h"
+
+// template 
+// constexpr bool testConstexprSpan(Span sp, std::size_t idx)
+// {
+// LIBCPP_ASSERT(noexcept(sp[idx]));
+
+// typename Span::reference r1 = sp[idx];
+// typename Span::reference r2 = *(sp.data() + idx);
+
+// return r1 == r2;
+// }
+
+// template 
+// void testRuntimeSpan(Span sp, std::size_t idx)
+// {
+// LIBCPP_ASSERT(noexcept(sp[idx]));
+
+// typename Span::reference r1 = sp[idx];
+// typename Span::reference r2 = *(sp.data() + idx);
+
+// assert(r1 == r2);
+// }
+
+// struct A{};
+// constexpr int iArr1[] = { 0,  1,  2,  3,  4,  5,  6,  7,  8,  9};
+//   int iArr2[] = {10, 11, 12, 13, 14, 15, 16, 17, 18, 19};
+
+// int main(int, char**)
+// {
+// static_assert(testConstexprSpan(std::span(iArr1, 1), 0), "");
+
+// static_assert(testConstexprSpan(std::span(iArr1, 2), 0), "");
+// static_assert(testConstexprSpan(std::span(iArr1, 2), 1), "");
+
+// static_assert(testConstexprSpan(std::span(iArr1, 3), 0), "");
+// static_assert(testConstexprSpan(std::span(iArr1, 3), 1), "");
+// static_assert(testConstexprSpan(std::span(iArr1, 3), 2), "");
+
+// static_assert(testConstexprSpan(std::span(iArr1, 4), 0), "");
+// static_assert(testConstexprSpan(std::span(iArr1, 4), 1), "");
+// static_assert(testConstexprSpan(std::span(iArr1, 4), 2), "");
+// 

[Lldb-commits] [lldb] [lld] [llvm] [libc] [libcxx] [flang] [compiler-rt] [clang-tools-extra] [clang] [GlobalISel] Add G_PREFETCH (PR #74863)

2023-12-11 Thread Stanislav Mekhanoshin via lldb-commits


@@ -1209,6 +1209,15 @@ def G_FENCE : GenericInstruction {
   let hasSideEffects = true;
 }
 
+// Generic opcode equivalent to the llvm.prefetch intrinsic.
+def G_PREFETCH : GenericInstruction {
+  let OutOperandList = (outs);
+  let InOperandList = (ins ptype0:$address, i32imm:$rw, i32imm:$locality, 
i32imm:$cachetype);
+  let hasSideEffects = true;
+  let mayLoad = true;
+  let mayStore = true;

rampitec wrote:

> should probably just be hasSideEffects. mayLoad/mayStore imply it needs a 
> memory operand and is an ordered memory reference when it doesn't have one

I could argue this is not a memory operation at all as it shall have no visible 
effects other than access speed, although practically it has ordering. You 
certainly do not want a prefetch to be moved past the loads which it was 
supposed to prefetch. I.e. in my view use of both mayLoad and mayStore is 
justified. Although we need to make sure it is not considered an aliased store 
or load from the AA point of view.

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


[Lldb-commits] [lldb] [lldb-dap] Emit declarations along with variables (PR #74865)

2023-12-11 Thread Alex Langford via lldb-commits

bulbazord wrote:

Is this extension to the protocol documented anywhere I can see? Or is this an 
ad-hoc thing? I think it would be useful to write down somewhere other than a 
commit message (in docs, comments, or otherwise) that this is an extension.

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -263,13 +252,6 @@ TagDecl *ClangASTSource::FindCompleteType(const TagDecl 
*decl) {
 
   TagDecl *candidate_tag_decl = const_cast(tag_type->getDecl());
 
-  // We have found a type by basename and we need to make sure the decl
-  // contexts are the same before we can try to complete this type with
-  // another
-  if (!TypeSystemClang::DeclsAreEquivalent(const_cast(decl),

Michael137 wrote:

`TypeSystemClang::DeclsAreEquivalent` is now unused it seems. Lets remove it?

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -64,6 +64,125 @@ bool 
lldb_private::contextMatches(llvm::ArrayRef context_chain,
   return true;
 }
 
+static CompilerContextKind ConvertTypeClass(lldb::TypeClass type_class) {
+  if (type_class == eTypeClassAny)
+return CompilerContextKind::AnyType;
+  uint16_t result = 0;
+  if (type_class & lldb::eTypeClassClass)
+result |= (uint16_t)CompilerContextKind::Class;
+  if (type_class & lldb::eTypeClassStruct)
+result |= (uint16_t)CompilerContextKind::Struct;
+  if (type_class & lldb::eTypeClassUnion)
+result |= (uint16_t)CompilerContextKind::Union;
+  if (type_class & lldb::eTypeClassEnumeration)
+result |= (uint16_t)CompilerContextKind::Enum;
+  if (type_class & lldb::eTypeClassFunction)
+result |= (uint16_t)CompilerContextKind::Function;
+  if (type_class & lldb::eTypeClassTypedef)
+result |= (uint16_t)CompilerContextKind::Typedef;
+  return (CompilerContextKind)result;
+}
+
+TypeQuery::TypeQuery(llvm::StringRef name, TypeQueryOptions options)
+: m_options(options) {
+  llvm::StringRef scope, basename;
+  lldb::TypeClass type_class = lldb::eTypeClassAny;
+  if (Type::GetTypeScopeAndBasename(name, scope, basename, type_class)) {
+if (scope.consume_front("::"))
+  m_options |= e_exact_match;
+if (!scope.empty()) {
+  std::pair scope_pair =
+  scope.split("::");
+  while (!scope_pair.second.empty()) {
+m_context.push_back({CompilerContextKind::AnyDeclContext,
+ ConstString(scope_pair.first.str())});
+scope_pair = scope_pair.second.split("::");
+  }
+  m_context.push_back({CompilerContextKind::AnyDeclContext,
+   ConstString(scope_pair.first.str())});
+}
+m_context.push_back(
+{ConvertTypeClass(type_class), ConstString(basename.str())});
+  } else {
+m_context.push_back(
+{CompilerContextKind::AnyType, ConstString(name.str())});
+  }
+}
+
+TypeQuery::TypeQuery(const CompilerDeclContext _ctx,
+ ConstString type_basename, TypeQueryOptions options)
+: m_options(options) {
+  // Always use an exact match if we are looking for a type in compiler 
context.
+  m_options |= e_exact_match;
+  m_context = decl_ctx.GetCompilerContext();
+  m_context.push_back({CompilerContextKind::AnyType, type_basename});
+}
+
+TypeQuery::TypeQuery(
+const llvm::ArrayRef ,
+TypeQueryOptions options)
+: m_context(context), m_options(options) {
+  // Always use an exact match if we are looking for a type in compiler 
context.
+  m_options |= e_exact_match;
+}
+
+TypeQuery::TypeQuery(const CompilerDecl , TypeQueryOptions options)
+: m_options(options) {
+  // Always for an exact match if we are looking for a type using a 
declaration.
+  m_options |= e_exact_match;
+  m_context = decl.GetCompilerContext();
+}
+
+ConstString TypeQuery::GetTypeBasename() const {
+  if (m_context.empty())
+return ConstString();
+  return m_context.back().name;
+}
+
+void TypeQuery::AddLanguage(LanguageType language) {
+  if (!m_languages)
+m_languages = LanguageSet();
+  m_languages->Insert(language);
+}
+
+bool TypeQuery::ContextMatches(
+llvm::ArrayRef context_chain) const {
+  if (GetExactMatch() || context_chain.size() == m_context.size())
+return ::contextMatches(context_chain, m_context);
+
+  // We don't have an exact match, we need to bottom m_context.size() items to
+  // match for a successful lookup.
+  if (context_chain.size() < m_context.size())
+return false; // Not enough items in context_chain to allow for a match.
+
+  size_t compare_count = context_chain.size() - m_context.size();
+  return ::contextMatches(
+  llvm::ArrayRef(context_chain.data() + compare_count,
+  m_context.size()),
+  m_context);
+}
+
+bool TypeQuery::LanguageMatches(lldb::LanguageType language) const {
+  // If we have no language filterm language always matches.
+  if (!m_languages.has_value())
+return true;
+  return (*m_languages)[language];
+}
+
+bool TypeResults::AlreadySearched(lldb_private::SymbolFile *sym_file) {
+  return !m_searched_symbol_files.insert(sym_file).second;

Michael137 wrote:

```suggestion
  return m_searched_symbol_files.contains(sym_file);
```

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -64,6 +64,125 @@ bool 
lldb_private::contextMatches(llvm::ArrayRef context_chain,
   return true;
 }
 
+static CompilerContextKind ConvertTypeClass(lldb::TypeClass type_class) {
+  if (type_class == eTypeClassAny)
+return CompilerContextKind::AnyType;
+  uint16_t result = 0;
+  if (type_class & lldb::eTypeClassClass)
+result |= (uint16_t)CompilerContextKind::Class;
+  if (type_class & lldb::eTypeClassStruct)
+result |= (uint16_t)CompilerContextKind::Struct;
+  if (type_class & lldb::eTypeClassUnion)
+result |= (uint16_t)CompilerContextKind::Union;
+  if (type_class & lldb::eTypeClassEnumeration)
+result |= (uint16_t)CompilerContextKind::Enum;
+  if (type_class & lldb::eTypeClassFunction)
+result |= (uint16_t)CompilerContextKind::Function;
+  if (type_class & lldb::eTypeClassTypedef)
+result |= (uint16_t)CompilerContextKind::Typedef;
+  return (CompilerContextKind)result;
+}
+
+TypeQuery::TypeQuery(llvm::StringRef name, TypeQueryOptions options)
+: m_options(options) {
+  llvm::StringRef scope, basename;
+  lldb::TypeClass type_class = lldb::eTypeClassAny;
+  if (Type::GetTypeScopeAndBasename(name, scope, basename, type_class)) {
+if (scope.consume_front("::"))
+  m_options |= e_exact_match;
+if (!scope.empty()) {
+  std::pair scope_pair =

Michael137 wrote:

don't need to block the PR on this, but wouldn't using the 
`split(SmallVector &)` overload make this whole block simpler? 

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits

https://github.com/Michael137 approved this pull request.

LGTM (just left some small comments)

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits

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


[Lldb-commits] [lldb] [lldb][draft] All ValueObjectSP instances are now valid (non-null) but have an error state (PR #74912)

2023-12-11 Thread Adrian Prantl via lldb-commits


@@ -1984,84 +1984,75 @@ void ValueObject::GetExpressionPath(Stream ,
   }
 }
 
-ValueObjectSP ValueObject::GetValueForExpressionPath(
-llvm::StringRef expression, ExpressionPathScanEndReason *reason_to_stop,
-ExpressionPathEndResultType *final_value_type,
+std::optional ValueObject::GetValueForExpressionPath(
+llvm::StringRef expression, ExpressionPathScanEndReason 
*reason_to_stop_ptr,
+ExpressionPathEndResultType *final_value_type_ptr,
 const GetValueForExpressionPathOptions ,
-ExpressionPathAftermath *final_task_on_target) {
-
-  ExpressionPathScanEndReason dummy_reason_to_stop =
-  ValueObject::eExpressionPathScanEndReasonUnknown;
-  ExpressionPathEndResultType dummy_final_value_type =
-  ValueObject::eExpressionPathEndResultTypeInvalid;
-  ExpressionPathAftermath dummy_final_task_on_target =
-  ValueObject::eExpressionPathAftermathNothing;
-
-  ValueObjectSP ret_val = GetValueForExpressionPath_Impl(
-  expression, reason_to_stop ? reason_to_stop : _reason_to_stop,
-  final_value_type ? final_value_type : _final_value_type, options,
-  final_task_on_target ? final_task_on_target
-   : _final_task_on_target);
-
-  if (!final_task_on_target ||
-  *final_task_on_target == ValueObject::eExpressionPathAftermathNothing)
-return ret_val;
-
-  if (ret_val.get() &&
-  ((final_value_type ? *final_value_type : dummy_final_value_type) ==
-   eExpressionPathEndResultTypePlain)) // I can only deref and takeaddress
-   // of plain objects
-  {
-if ((final_task_on_target ? *final_task_on_target
-  : dummy_final_task_on_target) ==
-ValueObject::eExpressionPathAftermathDereference) {
-  Status error;
-  ValueObjectSP final_value = ret_val->Dereference(error);
-  if (error.Fail() || !final_value.get()) {
-if (reason_to_stop)
-  *reason_to_stop =
-  ValueObject::eExpressionPathScanEndReasonDereferencingFailed;
-if (final_value_type)
-  *final_value_type = ValueObject::eExpressionPathEndResultTypeInvalid;
-return ValueObjectSP();
-  } else {
-if (final_task_on_target)
-  *final_task_on_target = ValueObject::eExpressionPathAftermathNothing;
-return final_value;
-  }
-}
-if (*final_task_on_target ==
-ValueObject::eExpressionPathAftermathTakeAddress) {
-  Status error;
-  ValueObjectSP final_value = ret_val->AddressOf(error);
-  if (error.Fail() || !final_value.get()) {
-if (reason_to_stop)
-  *reason_to_stop =
-  ValueObject::eExpressionPathScanEndReasonTakingAddressFailed;
-if (final_value_type)
-  *final_value_type = ValueObject::eExpressionPathEndResultTypeInvalid;
-return ValueObjectSP();
-  } else {
-if (final_task_on_target)
-  *final_task_on_target = ValueObject::eExpressionPathAftermathNothing;
-return final_value;
-  }
-}
+ExpressionPathAftermath *final_task_on_target_ptr) {
+
+  auto stop_reason_unknown = eExpressionPathScanEndReasonUnknown;
+  auto value_type_invalid = eExpressionPathEndResultTypeInvalid;
+  auto final_task_nothing = eExpressionPathAftermathNothing;
+
+  auto ret_value = GetValueForExpressionPath_Impl(
+  expression,
+  reason_to_stop_ptr ? reason_to_stop_ptr : _reason_unknown,
+  final_value_type_ptr ? final_value_type_ptr : _type_invalid,
+  options,
+  final_task_on_target_ptr ? final_task_on_target_ptr
+   : _task_nothing);
+
+  // The caller knows that nothing happened because `final_task_on_target` 
still
+  // has its original value.
+  if (!ret_value)
+return {};
+
+  if (!final_value_type_ptr)
+return ret_value;
+
+  if ((*final_value_type_ptr) != eExpressionPathEndResultTypePlain)
+return ret_value;
+
+  if (!final_task_on_target_ptr)
+return ret_value;
+
+  ExpressionPathAftermath _task_on_target = (*final_task_on_target_ptr);
+  ExpressionPathScanEndReason stop_reason_for_error;
+  // The method can only dereference and take the address of plain objects.
+  switch (final_task_on_target) {
+  case eExpressionPathAftermathNothing: {
+return ret_value;
+  }
+  case eExpressionPathAftermathDereference: {
+ret_value = ret_value.value()->Dereference();
+stop_reason_for_error = eExpressionPathScanEndReasonDereferencingFailed;
+  }
+  case eExpressionPathAftermathTakeAddress: {
+ret_value = ret_value.value()->AddressOf();
+stop_reason_for_error = eExpressionPathScanEndReasonTakingAddressFailed;
+  }
+  }
+
+  if (ret_value && ret_value.value()->GetError().Success()) {
+final_task_on_target = eExpressionPathAftermathNothing;
+return ret_value;
+  } else {

adrian-prantl wrote:

LLVM coding style prefers leaving off `else` after `return`.

https://github.com/llvm/llvm-project/pull/74912

[Lldb-commits] [mlir] [libc] [lld] [libcxxabi] [compiler-rt] [lldb] [llvm] [clang-tools-extra] [libunwind] [libcxx] [clang] [openmp] [flang] [C23] Implement N3018: The constexpr specifier for object d

2023-12-11 Thread Guillot Tony via lldb-commits

to268 wrote:

I have found no major issues with the C23 `auto` keyword.
There is a minor improvement that I've found in the test cases.

Concerning N3006 (AKA: Underspecified object declarations), I haven't reviewed 
yet the compatibility with the `constexpr` keyword, since I haven't work much 
on it yet.  
 

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


[Lldb-commits] [openmp] [lldb] [llvm] [libcxx] [libc] [clang-tools-extra] [compiler-rt] [lld] [flang] [libcxxabi] [clang] [mlir] [libunwind] [C23] Implement N3018: The constexpr specifier for object d

2023-12-11 Thread Guillot Tony via lldb-commits


@@ -0,0 +1,287 @@
+// RUN: %clang_cc1 -std=c2x -verify -triple x86_64 -pedantic -Wno-conversion 
-Wno-constant-conversion -Wno-div-by-zero %s
+
+// Check that constexpr only applies to variables.
+constexpr void f0() {} // expected-error {{'constexpr' can only be used in 
variable declarations}}
+constexpr const int f1() { return 0; } // expected-error {{'constexpr' can 
only be used in variable declarations}}
+
+constexpr struct S1 { int f; }; //expected-error {{struct cannot be marked 
constexpr}}
+constexpr struct S2 ; // expected-error {{struct cannot be marked constexpr}}
+constexpr union U1; // expected-error {{union cannot be marked constexpr}}
+constexpr union U2 {int a; float b;}; // expected-error {{union cannot be 
marked constexpr}}
+constexpr enum E1 {A = 1, B = 2} ; // expected-error {{enum cannot be marked 
constexpr}}
+struct S3 {
+  static constexpr int f = 0; // expected-error {{type name does not allow 
storage class}}
+  // expected-error@-1 {{type name does not allow constexpr}}
+  // expected-error@-2 {{expected ';' at end}}
+  constexpr int f1 = 0;
+  // expected-error@-1 {{type name does not allow constexpr}}
+  // expected-error@-2 {{expected ';' at end}}
+};
+
+constexpr; // expected-error {{'constexpr' can only be used in variable 
declarations}}
+constexpr int V1 = 3;
+constexpr float V2 = 7.0;
+int V3 = (constexpr)3; // expected-error {{expected expression}}
+
+void f2() {
+  constexpr int a = 0;
+  constexpr float b = 1.7f;
+}
+
+// Check how constexpr works with other storage-class specifiers.
+constexpr auto V4 = 1;
+constexpr static auto V5 = 1;
+constexpr static const auto V6 = 1;
+constexpr static const int V7 = 1;
+constexpr static int V8 = 1;

to268 wrote:

I would preferably suggest to add a couple of `constexpr auto` tests, theses 
cases bellow should be enough to make sure that no divergence has been 
introduced.
```c
constexpr auto Ulong = 1L;
constexpr auto CompoundLiterral = (int){13};
constexpr auto DoubleCast = (double)(1 / 3);
constexpr auto String = "this is a string";
constexpr signed auto Long = 1L; // expected-error {{'auto' cannot be signed or 
unsigned}}
```

Adding some `_Static_assert` would be better to also make sure that the `auto` 
keyword is on par when adding the `constexpr` keyword.
```c
_Static_assert(_Generic(Ulong, long : 1));
_Static_assert(_Generic(CompoundLiterral, int : 1));
_Static_assert(_Generic(DoubleCast, double : 1));
_Static_assert(_Generic(String, char* : 1));
```

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


[Lldb-commits] [mlir] [lldb] [openmp] [llvm] [clang] [libcxxabi] [compiler-rt] [clang-tools-extra] [flang] [libcxx] [MachineCopyPropagation] When the source of PreviousCopy is undef, we cannot replace

2023-12-11 Thread David Green via lldb-commits

davemgreen wrote:

I don't believe the undef is the issue - I think the issue is that 
AArch64InstrInfo::isCopyInstrImpl is saying that a W-reg orr is a copy, even if 
it is really a zextend because the entire X output register is depended upon.

Can you try and add something to isCopyInstImpl instead, that says: If the 
register is virtual then it should not be a subreg, and if the register is 
physical then there should not be an implicit def of the X reg. Would that 
solve your issue, and would it cause other problems in AArch64 codegen? Thanks

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -1446,23 +1446,23 @@ void SymbolFilePDB::AddSymbols(lldb_private::Symtab 
) {
   symtab.Finalize();
 }
 
-void SymbolFilePDB::FindTypes(
-lldb_private::ConstString name, const CompilerDeclContext _decl_ctx,
-uint32_t max_matches,
-llvm::DenseSet _symbol_files,
-lldb_private::TypeMap ) {
-  std::lock_guard guard(GetModuleMutex());
-  if (!name)
-return;
-  if (!DeclContextMatchesThisSymbolFile(parent_decl_ctx))
-return;
-
-  searched_symbol_files.clear();
-  searched_symbol_files.insert(this);
-
-  // There is an assumption 'name' is not a regex
-  FindTypesByName(name.GetStringRef(), parent_decl_ctx, max_matches, types);
-}
+// void SymbolFilePDB::FindTypes(
+// lldb_private::ConstString name, const CompilerDeclContext
+// _decl_ctx, uint32_t max_matches,
+// llvm::DenseSet _symbol_files,
+// lldb_private::TypeMap ) {
+//   std::lock_guard guard(GetModuleMutex());
+//   if (!name)
+// return;
+//   if (!DeclContextMatchesThisSymbolFile(parent_decl_ctx))
+// return;
+
+//   searched_symbol_files.clear();
+//   searched_symbol_files.insert(this);
+
+//   // There is an assumption 'name' is not a regex
+//   FindTypesByName(name.GetStringRef(), parent_decl_ctx, max_matches, types);
+// }

Michael137 wrote:

Can we remove this?

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -9070,6 +9070,66 @@ size_t TypeSystemClang::DeclGetFunctionNumArguments(void 
*opaque_decl) {
 return 0;
 }
 
+static CompilerContextKind GetCompilerKind(clang::Decl::Kind clang_kind,
+   clang::DeclContext *decl_ctx) {

Michael137 wrote:

```suggestion
   clang::DeclContext const *decl_ctx) {
```

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -1859,17 +1851,11 @@ lldb::SBTypeList SBTarget::FindTypes(const char 
*typename_cstr) {
   if (typename_cstr && typename_cstr[0] && target_sp) {
 ModuleList  = target_sp->GetImages();
 ConstString const_typename(typename_cstr);
-bool exact_match = false;
-TypeList type_list;
-llvm::DenseSet searched_symbol_files;
-images.FindTypes(nullptr, const_typename, exact_match, UINT32_MAX,
- searched_symbol_files, type_list);
-
-for (size_t idx = 0; idx < type_list.GetSize(); idx++) {
-  TypeSP type_sp(type_list.GetTypeAtIndex(idx));
-  if (type_sp)
-sb_type_list.Append(SBType(type_sp));
-}
+TypeQuery query(typename_cstr);
+TypeResults results;
+images.FindTypes(nullptr, query, results);
+for (const TypeSP _sp : results.GetTypeMap().Types())

Michael137 wrote:

Should we add a debug-assert here (or maybe in `InsertUnique`) that tests 
`type_sp != nullptr`? Or are we guaranteed somewhere that these won't be 
`nullptr`?

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -12,33 +12,32 @@ class UniqueTypesTestCase4(TestBase):
 def do_test(self, debug_flags):
 """Test that we display the correct template instantiation."""
 self.build(dictionary=debug_flags)
+exe = self.getBuildArtifact("a.out")
+print(exe)
 lldbutil.run_to_source_breakpoint(
 self, "// Set breakpoint here", lldb.SBFileSpec("main.cpp")
 )
 # FIXME: these should successfully print the values
 self.expect(
-"expression ns::Foo::value", substrs=["no member named"], 
error=True
+"print ns::Foo::value", substrs=["no template named 'Foo' 
in namespace 'ns'"], error=True

Michael137 wrote:

why change these to `print`?

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -12,33 +12,32 @@ class UniqueTypesTestCase4(TestBase):
 def do_test(self, debug_flags):
 """Test that we display the correct template instantiation."""
 self.build(dictionary=debug_flags)
+exe = self.getBuildArtifact("a.out")
+print(exe)

Michael137 wrote:

leftover from debugging?

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -12,33 +12,32 @@ class UniqueTypesTestCase4(TestBase):
 def do_test(self, debug_flags):
 """Test that we display the correct template instantiation."""
 self.build(dictionary=debug_flags)
+exe = self.getBuildArtifact("a.out")
+print(exe)
 lldbutil.run_to_source_breakpoint(
 self, "// Set breakpoint here", lldb.SBFileSpec("main.cpp")
 )
 # FIXME: these should successfully print the values
 self.expect(
-"expression ns::Foo::value", substrs=["no member named"], 
error=True
+"print ns::Foo::value", substrs=["no template named 'Foo' 
in namespace 'ns'"], error=True
 )
 self.expect(
-"expression ns::Foo::value", substrs=["no member named"], 
error=True
+"print ns::Foo::value", substrs=["no template named 'Foo' in 
namespace 'ns'"], error=True
 )
 self.expect(
-"expression ns::Bar::value", substrs=["no member named"], 
error=True
+"print ns::Bar::value", substrs=["no template named 'Bar' 
in namespace 'ns'"], error=True
 )
 self.expect(
-"expression ns::Bar::value", substrs=["no member named"], 
error=True
+"print ns::Bar::value", substrs=["no template named 'Bar' in 
namespace 'ns'"], error=True
 )
 self.expect(
-"expression ns::FooDouble::value",
-substrs=["Couldn't look up symbols"],
-error=True,
+"print ns::FooDouble::value", substrs=["(double) 0"]
 )
 self.expect(
-"expression ns::FooInt::value",
-substrs=["Couldn't look up symbols"],
-error=True,
+"print ns::FooInt::value", substrs=["(int) 0"]

Michael137 wrote:

`expect_expr`

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -73,9 +73,22 @@ class DWARFDIE : public DWARFBaseDIE {
   std::vector GetDeclContextDIEs() const;
 
   /// Return this DIE's decl context as it is needed to look up types
-  /// in Clang's -gmodules debug info format.
+  /// in Clang modules. This context will include any modules or functions that
+  /// the type is declared in so an exact module match can be efficiently made.
   std::vector GetDeclContext() const;
 
+  /// Get a context to a type so it can be looked up.
+  ///
+  /// This function uses the current DIE to fill in a CompilerContext array
+  /// that is suitable for type lookup for comparison to a TypeQuery's compiler
+  /// context (TypeQuery::GetContextRef()). If this DIE represents a named 
type,
+  /// it should fill out the compiler context with the type itself as the last
+  /// entry. The declaration context should be above the type and stop at an
+  /// appropriate time, like either the translation unit or at a function
+  /// context. This is designed to allow users to efficiently look for types
+  /// using a full or partial CompilerContext array.
+  std::vector GetTypeLookupContext() const;

Michael137 wrote:

Why can't we extend `GetDeclContext` to behave like `GetTypeLookupContext`? I'm 
probably missing something subtle about clang module lookup

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -12,33 +12,32 @@ class UniqueTypesTestCase4(TestBase):
 def do_test(self, debug_flags):
 """Test that we display the correct template instantiation."""
 self.build(dictionary=debug_flags)
+exe = self.getBuildArtifact("a.out")
+print(exe)
 lldbutil.run_to_source_breakpoint(
 self, "// Set breakpoint here", lldb.SBFileSpec("main.cpp")
 )
 # FIXME: these should successfully print the values
 self.expect(
-"expression ns::Foo::value", substrs=["no member named"], 
error=True
+"print ns::Foo::value", substrs=["no template named 'Foo' 
in namespace 'ns'"], error=True
 )
 self.expect(
-"expression ns::Foo::value", substrs=["no member named"], 
error=True
+"print ns::Foo::value", substrs=["no template named 'Foo' in 
namespace 'ns'"], error=True
 )
 self.expect(
-"expression ns::Bar::value", substrs=["no member named"], 
error=True
+"print ns::Bar::value", substrs=["no template named 'Bar' 
in namespace 'ns'"], error=True
 )
 self.expect(
-"expression ns::Bar::value", substrs=["no member named"], 
error=True
+"print ns::Bar::value", substrs=["no template named 'Bar' in 
namespace 'ns'"], error=True
 )
 self.expect(
-"expression ns::FooDouble::value",
-substrs=["Couldn't look up symbols"],
-error=True,
+"print ns::FooDouble::value", substrs=["(double) 0"]

Michael137 wrote:

this can be now turned into `expect_expr`

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -1696,16 +1696,16 @@ static size_t LookupTypeInModule(Target *target,
  CommandInterpreter , Stream ,
  Module *module, const char *name_cstr,
  bool name_is_regex) {
-  TypeList type_list;
   if (module && name_cstr && name_cstr[0]) {
-const uint32_t max_num_matches = UINT32_MAX;
-bool name_is_fully_qualified = false;
-
-ConstString name(name_cstr);
-llvm::DenseSet searched_symbol_files;
-module->FindTypes(name, name_is_fully_qualified, max_num_matches,
-  searched_symbol_files, type_list);
+TypeQuery query(name_cstr);
+TypeResults results;
+module->FindTypes(query, results);
 
+TypeList type_list;
+SymbolContext sc;
+if (module)
+  sc.module_sp = module->shared_from_this();
+sc.SortTypeList(results.GetTypeMap(), type_list);

Michael137 wrote:

I see this type-map sorting used to also be done in the old `FindTypes` APIs, 
but can you leave a comment on why we need to do this?

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -146,6 +133,9 @@ class TypeSystem : public PluginInterface,
   virtual CompilerDeclContext
   GetCompilerDeclContextForType(const CompilerType );
 
+  virtual std::vector
+  DeclContextGetCompilerContext(void *opaque_decl_ctx);

Michael137 wrote:

could this function be marked `const`?

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -122,6 +106,9 @@ class TypeSystem : public PluginInterface,
   virtual CompilerType DeclGetFunctionArgumentType(void *opaque_decl,
size_t arg_idx);
 
+  virtual std::vector
+  DeclGetCompilerContext(void *opaque_decl);

Michael137 wrote:

could this function be marked `const`?

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


[Lldb-commits] [lldb] [lldb][NFC] Simplify DWARRFDeclContext::GetQualifiedName (PR #74788)

2023-12-11 Thread Felipe de Azevedo Piovezan via lldb-commits

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


[Lldb-commits] [lldb] 06d6af7 - [lldb][NFC] Simplify DWARRFDeclContext::GetQualifiedName (#74788)

2023-12-11 Thread via lldb-commits

Author: Felipe de Azevedo Piovezan
Date: 2023-12-11T11:16:36-03:00
New Revision: 06d6af72fb6f87cebe90ab96fa56fb88f53d5f66

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

LOG: [lldb][NFC] Simplify DWARRFDeclContext::GetQualifiedName (#74788)

This commit factors out the logic building each component of a qualified
name into its own function so that it may be reused by a future commit,
while also simplifying the logic of assembling these pieces together by
using llvm::interleave.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp
index 44e7602279013..44421c0eda3ee 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp
@@ -7,10 +7,27 @@
 
//===--===//
 
 #include "DWARFDeclContext.h"
+#include "llvm/Support/raw_ostream.h"
 
 using namespace lldb_private::dwarf;
 using namespace lldb_private::plugin::dwarf;
 
+/// Returns the name of `entry` if it has one, or the appropriate "anonymous
+/// {namespace, class, struct, union}".
+static const char *GetName(DWARFDeclContext::Entry entry) {
+  if (entry.name != nullptr)
+return entry.name;
+  if (entry.tag == DW_TAG_namespace)
+return "(anonymous namespace)";
+  if (entry.tag == DW_TAG_class_type)
+return "(anonymous class)";
+  if (entry.tag == DW_TAG_structure_type)
+return "(anonymous struct)";
+  if (entry.tag == DW_TAG_union_type)
+return "(anonymous union)";
+  return "(anonymous)";
+}
+
 const char *DWARFDeclContext::GetQualifiedName() const {
   if (m_qualified_name.empty()) {
 // The declaration context array for a class named "foo" in namespace
@@ -26,26 +43,10 @@ const char *DWARFDeclContext::GetQualifiedName() const {
   m_qualified_name.append(m_entries[0].name);
 }
   } else {
-collection::const_reverse_iterator pos;
-collection::const_reverse_iterator begin = m_entries.rbegin();
-collection::const_reverse_iterator end = m_entries.rend();
-for (pos = begin; pos != end; ++pos) {
-  if (pos != begin)
-m_qualified_name.append("::");
-  if (pos->name == nullptr) {
-if (pos->tag == DW_TAG_namespace)
-  m_qualified_name.append("(anonymous namespace)");
-else if (pos->tag == DW_TAG_class_type)
-  m_qualified_name.append("(anonymous class)");
-else if (pos->tag == DW_TAG_structure_type)
-  m_qualified_name.append("(anonymous struct)");
-else if (pos->tag == DW_TAG_union_type)
-  m_qualified_name.append("(anonymous union)");
-else
-  m_qualified_name.append("(anonymous)");
-  } else
-m_qualified_name.append(pos->name);
-}
+llvm::raw_string_ostream string_stream(m_qualified_name);
+llvm::interleave(
+llvm::reverse(m_entries), string_stream,
+[&](auto entry) { string_stream << GetName(entry); }, "::");
   }
 }
   }



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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -502,11 +499,8 @@ lldb::SBTypeList SBModule::FindTypes(const char *type) {
 retval.Append(SBType(compiler_type));
   }
 } else {
-  for (size_t idx = 0; idx < type_list.GetSize(); idx++) {
-TypeSP type_sp(type_list.GetTypeAtIndex(idx));
-if (type_sp)
-  retval.Append(SBType(type_sp));
-  }
+  for (const TypeSP _sp : results.GetTypeMap().Types())
+retval.Append(SBType(type_sp));

Michael137 wrote:

Should we add a debug-assert here (or maybe in `InsertUnique`) that tests 
`type_sp != nullptr`?

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -45,6 +66,286 @@ struct CompilerContext {
 bool contextMatches(llvm::ArrayRef context_chain,
 llvm::ArrayRef pattern);
 
+FLAGS_ENUM(TypeQueryOptions){
+e_none = 0u,
+/// If set TypeQuery::m_context contains an exact context that must match
+/// the full context. If not set TypeQuery::m_context can contain a partial
+/// type match where the full context isn't fully specified.
+e_exact_match = (1u << 0),
+/// If set, TypeQuery::m_context is a clang module compiler context. If not
+/// set TypeQuery::m_context is normal type lookup context.
+e_module_search = (1u << 1),
+/// When true, the find types call should stop the query as soon as a 
single
+/// matching type is found. When false, the type query should find all
+/// matching types.
+e_find_one = (1u << 2),
+};
+LLDB_MARK_AS_BITMASK_ENUM(TypeQueryOptions)
+
+/// A class that contains all state required for type lookups.
+///
+/// Using a TypeQuery class for matching types simplifies the internal APIs we
+/// need to implement type lookups in LLDB. Type lookups can fully specify the
+/// exact typename by filling out a complete or partial CompilerContext array.
+/// This allows for powerful searches and also allows the SymbolFile classes to
+/// use the m_context array to lookup types by basename, then eliminate
+/// potential matches without having to resolve types into each TypeSystem. 
This
+/// makes type lookups vastly more efficient and allows the SymbolFile objects
+/// to stop looking up types when the type matching is complete, like if we are
+/// looking for only a single type in our search.
+class TypeQuery {
+public:
+  TypeQuery() = delete;
+
+  /// Construct a type match object using a fully or partially qualified name.
+  ///
+  /// The specified \a type_name will be chopped up and the m_context will be
+  /// populated by separating the string by looking for "::". We do this 
because
+  /// symbol files have indexes that contain only the type's basename. This 
also
+  /// allows symbol files to efficiently not realize types that don't match the
+  /// specified context. Example of \a type_name values that can be specified
+  /// include:
+  ///   "foo": Look for any type whose basename matches "foo".
+  /// If \a exact_match is true, then the type can't be contained in any
+  /// declaration context like a namespace, class, or other containing
+  /// scope.
+  /// If \a exact match is false, then we will find all matches including
+  /// ones that are contained in other declaration contexts, including top
+  /// level types.
+  ///   "foo::bar": Look for any type whose basename matches "bar" but make 
sure
+  /// its parent declaration context is any named declaration context
+  /// (namespace, class, struct, etc) whose name matches "foo".
+  /// If \a exact_match is true, then the "foo" declaration context must
+  /// appear at the source file level or inside of a function.
+  /// If \a exact match is false, then the "foo" declaration context can
+  /// be contained in any other declaration contexts.
+  ///   "class foo": Only match types that are classes whose basename matches
+  /// "foo".
+  ///   "struct foo": Only match types that are structures whose basename
+  /// matches "foo".
+  ///   "class foo::bar": Only match types that are classes whose basename
+  /// matches "bar" and that are contained in any named declaration context
+  /// named "foo".

Michael137 wrote:

Can we also document the special behaviour of a query that begins with `::`? It 
looks like in those cases we set `exact_match` to `true`?

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


[Lldb-commits] [lldb] [lldb][NFC] Simplify DWARRFDeclContext::GetQualifiedName (PR #74788)

2023-12-11 Thread Michael Buch via lldb-commits

https://github.com/Michael137 approved this pull request.

LGTM

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -437,26 +437,25 @@ lldb::SBType SBModule::FindFirstType(const char 
*name_cstr) {
   LLDB_INSTRUMENT_VA(this, name_cstr);
 
   ModuleSP module_sp(GetSP());
-  if (!name_cstr || !module_sp)
-return {};
-  SymbolContext sc;
-  const bool exact_match = false;
-  ConstString name(name_cstr);
+  if (name_cstr && module_sp) {
+ConstString name(name_cstr);
+TypeQuery query(name.GetStringRef(), TypeQueryOptions::e_find_one);
+TypeResults results;
+module_sp->FindTypes(query, results);
+TypeSP type_sp = results.GetFirstType();
+if (type_sp)
+  return SBType(type_sp);

Michael137 wrote:

We previously would only return `sb_type` if `sb_type.IsValid() == true`. Does 
this mean we can now return an "invalid" SBType? Or is this checked elsewhere 
now?

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -437,26 +437,25 @@ lldb::SBType SBModule::FindFirstType(const char 
*name_cstr) {
   LLDB_INSTRUMENT_VA(this, name_cstr);
 
   ModuleSP module_sp(GetSP());
-  if (!name_cstr || !module_sp)

Michael137 wrote:

why did we get rid of the early return here?

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


[Lldb-commits] [lldb] [lldb][NFC] Simplify DWARRFDeclContext::GetQualifiedName (PR #74788)

2023-12-11 Thread Felipe de Azevedo Piovezan via lldb-commits

https://github.com/felipepiovezan updated 
https://github.com/llvm/llvm-project/pull/74788

>From 19452a77fbaa8376686ae9fcdb6c675621f515d8 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Thu, 7 Dec 2023 15:45:05 -0800
Subject: [PATCH] [lldb][NFC] Simplify DWARRFDeclContext::GetQualifiedName

This commit factors out the logic building each component of a qualified name
into its own function so that it may be reused by a future commit, while also
simplifying the logic of assembling these pieces together by using
llvm::interleave.
---
 .../SymbolFile/DWARF/DWARFDeclContext.cpp | 41 ++-
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp
index 44e76022790130..44421c0eda3eec 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp
@@ -7,10 +7,27 @@
 
//===--===//
 
 #include "DWARFDeclContext.h"
+#include "llvm/Support/raw_ostream.h"
 
 using namespace lldb_private::dwarf;
 using namespace lldb_private::plugin::dwarf;
 
+/// Returns the name of `entry` if it has one, or the appropriate "anonymous
+/// {namespace, class, struct, union}".
+static const char *GetName(DWARFDeclContext::Entry entry) {
+  if (entry.name != nullptr)
+return entry.name;
+  if (entry.tag == DW_TAG_namespace)
+return "(anonymous namespace)";
+  if (entry.tag == DW_TAG_class_type)
+return "(anonymous class)";
+  if (entry.tag == DW_TAG_structure_type)
+return "(anonymous struct)";
+  if (entry.tag == DW_TAG_union_type)
+return "(anonymous union)";
+  return "(anonymous)";
+}
+
 const char *DWARFDeclContext::GetQualifiedName() const {
   if (m_qualified_name.empty()) {
 // The declaration context array for a class named "foo" in namespace
@@ -26,26 +43,10 @@ const char *DWARFDeclContext::GetQualifiedName() const {
   m_qualified_name.append(m_entries[0].name);
 }
   } else {
-collection::const_reverse_iterator pos;
-collection::const_reverse_iterator begin = m_entries.rbegin();
-collection::const_reverse_iterator end = m_entries.rend();
-for (pos = begin; pos != end; ++pos) {
-  if (pos != begin)
-m_qualified_name.append("::");
-  if (pos->name == nullptr) {
-if (pos->tag == DW_TAG_namespace)
-  m_qualified_name.append("(anonymous namespace)");
-else if (pos->tag == DW_TAG_class_type)
-  m_qualified_name.append("(anonymous class)");
-else if (pos->tag == DW_TAG_structure_type)
-  m_qualified_name.append("(anonymous struct)");
-else if (pos->tag == DW_TAG_union_type)
-  m_qualified_name.append("(anonymous union)");
-else
-  m_qualified_name.append("(anonymous)");
-  } else
-m_qualified_name.append(pos->name);
-}
+llvm::raw_string_ostream string_stream(m_qualified_name);
+llvm::interleave(
+llvm::reverse(m_entries), string_stream,
+[&](auto entry) { string_stream << GetName(entry); }, "::");
   }
 }
   }

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


[Lldb-commits] [lldb] [lldb][NFC] Simplify DWARRFDeclContext::GetQualifiedName (PR #74788)

2023-12-11 Thread Felipe de Azevedo Piovezan via lldb-commits

https://github.com/felipepiovezan updated 
https://github.com/llvm/llvm-project/pull/74788

>From 5a5309c1c81fadb0378f1fa821798471f00f9b29 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Thu, 7 Dec 2023 15:45:05 -0800
Subject: [PATCH] [lldb][NFC] Simplify DWARRFDeclContext::GetQualifiedName

This commit factors out the logic building each component of a qualified name
into its own function so that it may be reused by a future commit, while also
simplifying the logic of assembling these pieces together by using
llvm::interleave.
---
 .../SymbolFile/DWARF/DWARFDeclContext.cpp | 42 ++-
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp
index 44e7602279013..5ce04673fa6d4 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDeclContext.cpp
@@ -7,10 +7,28 @@
 
//===--===//
 
 #include "DWARFDeclContext.h"
+#include "llvm/Support/raw_ostream.h"
+
 
 using namespace lldb_private::dwarf;
 using namespace lldb_private::plugin::dwarf;
 
+/// Returns the name of `entry` if it has one, or the appropriate "anonymous
+/// {namespace, class, struct, union}".
+static const char *GetName(DWARFDeclContext::Entry entry) {
+  if (entry.name != nullptr)
+return entry.name;
+  if (entry.tag == DW_TAG_namespace)
+return "(anonymous namespace)";
+  if (entry.tag == DW_TAG_class_type)
+return "(anonymous class)";
+  if (entry.tag == DW_TAG_structure_type)
+return "(anonymous struct)";
+  if (entry.tag == DW_TAG_union_type)
+return "(anonymous union)";
+  return "(anonymous)";
+}
+
 const char *DWARFDeclContext::GetQualifiedName() const {
   if (m_qualified_name.empty()) {
 // The declaration context array for a class named "foo" in namespace
@@ -26,26 +44,10 @@ const char *DWARFDeclContext::GetQualifiedName() const {
   m_qualified_name.append(m_entries[0].name);
 }
   } else {
-collection::const_reverse_iterator pos;
-collection::const_reverse_iterator begin = m_entries.rbegin();
-collection::const_reverse_iterator end = m_entries.rend();
-for (pos = begin; pos != end; ++pos) {
-  if (pos != begin)
-m_qualified_name.append("::");
-  if (pos->name == nullptr) {
-if (pos->tag == DW_TAG_namespace)
-  m_qualified_name.append("(anonymous namespace)");
-else if (pos->tag == DW_TAG_class_type)
-  m_qualified_name.append("(anonymous class)");
-else if (pos->tag == DW_TAG_structure_type)
-  m_qualified_name.append("(anonymous struct)");
-else if (pos->tag == DW_TAG_union_type)
-  m_qualified_name.append("(anonymous union)");
-else
-  m_qualified_name.append("(anonymous)");
-  } else
-m_qualified_name.append(pos->name);
-}
+llvm::raw_string_ostream string_stream(m_qualified_name);
+llvm::interleave(
+llvm::reverse(m_entries), string_stream,
+[&](auto entry) { string_stream << GetName(entry); }, "::");
   }
 }
   }

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


[Lldb-commits] [lldb] Make only one function that needs to be implemented when searching for types (PR #74786)

2023-12-11 Thread Michael Buch via lldb-commits


@@ -45,6 +66,286 @@ struct CompilerContext {
 bool contextMatches(llvm::ArrayRef context_chain,
 llvm::ArrayRef pattern);
 
+FLAGS_ENUM(TypeQueryOptions){
+e_none = 0u,
+/// If set TypeQuery::m_context contains an exact context that must match
+/// the full context. If not set TypeQuery::m_context can contain a partial
+/// type match where the full context isn't fully specified.
+e_exact_match = (1u << 0),
+/// If set, TypeQuery::m_context is a clang module compiler context. If not
+/// set TypeQuery::m_context is normal type lookup context.
+e_module_search = (1u << 1),
+/// When true, the find types call should stop the query as soon as a 
single
+/// matching type is found. When false, the type query should find all
+/// matching types.
+e_find_one = (1u << 2),
+};
+LLDB_MARK_AS_BITMASK_ENUM(TypeQueryOptions)
+
+/// A class that contains all state required for type lookups.
+///
+/// Using a TypeQuery class for matching types simplifies the internal APIs we
+/// need to implement type lookups in LLDB. Type lookups can fully specify the
+/// exact typename by filling out a complete or partial CompilerContext array.
+/// This allows for powerful searches and also allows the SymbolFile classes to
+/// use the m_context array to lookup types by basename, then eliminate
+/// potential matches without having to resolve types into each TypeSystem. 
This
+/// makes type lookups vastly more efficient and allows the SymbolFile objects
+/// to stop looking up types when the type matching is complete, like if we are
+/// looking for only a single type in our search.
+class TypeQuery {
+public:
+  TypeQuery() = delete;
+
+  /// Construct a type match object using a fully or partially qualified name.
+  ///
+  /// The specified \a type_name will be chopped up and the m_context will be
+  /// populated by separating the string by looking for "::". We do this 
because
+  /// symbol files have indexes that contain only the type's basename. This 
also
+  /// allows symbol files to efficiently not realize types that don't match the
+  /// specified context. Example of \a type_name values that can be specified
+  /// include:
+  ///   "foo": Look for any type whose basename matches "foo".
+  /// If \a exact_match is true, then the type can't be contained in any
+  /// declaration context like a namespace, class, or other containing
+  /// scope.
+  /// If \a exact match is false, then we will find all matches including
+  /// ones that are contained in other declaration contexts, including top
+  /// level types.
+  ///   "foo::bar": Look for any type whose basename matches "bar" but make 
sure
+  /// its parent declaration context is any named declaration context
+  /// (namespace, class, struct, etc) whose name matches "foo".
+  /// If \a exact_match is true, then the "foo" declaration context must
+  /// appear at the source file level or inside of a function.
+  /// If \a exact match is false, then the "foo" declaration context can
+  /// be contained in any other declaration contexts.
+  ///   "class foo": Only match types that are classes whose basename matches
+  /// "foo".
+  ///   "struct foo": Only match types that are structures whose basename
+  /// matches "foo".
+  ///   "class foo::bar": Only match types that are classes whose basename
+  /// matches "bar" and that are contained in any named declaration context
+  /// named "foo".
+  ///
+  /// \param[in] type_name
+  ///   A fully or partially qualified type name. This name will be parsed and
+  ///   broken up and the m_context will be populated with the various parts of
+  ///   the name. This typename can be prefixed with "struct ", "class ",
+  ///   "union", "enum " or "typedef " before the actual type name to limit the
+  ///   results of the types that match. The declaration context can be
+  ///   specified with the "::" string. like "a::b::my_type".
+  ///
+  /// \param[in] options A set of boolean enumeration flags from the
+  ///   TypeQueryOptions enumerations. \see TypeQueryOptions.
+  TypeQuery(llvm::StringRef name, TypeQueryOptions options = e_none);

Michael137 wrote:

The comments refer to a parameter called `type_name`, but it's called `name`

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


  1   2   >