llvm-project.git - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author
2024-06-21	Reland "[lldb][ObjC] Don't query objective-c runtime for decls in C++ contexts"	Michael Buch
	This relands https://github.com/llvm/llvm-project/pull/95963. It had to be reverted because the `TestEarlyProcessLaunch.py` test was failing on the incremental macOS bots. The test failed because it was relying on expression log output from the ObjC introspection routines (but was the expression was called from a C++ context). The relanded patch simply ensures that the test runs the expressions as `ObjC` expressions. When LLDB isn't able to find a `clang::Decl` in response to a `FindExternalVisibleDeclsByName`, it will fall-back to looking into the Objective-C runtime for that decl. This ends up doing a lot of work which isn't necessary when we're debugging a C++ program. This patch makes the ObjC lookup conditional on the language that the ExpressionParser deduced (which can be explicitly set using the `expr --language` option or is set implicitly if we're stopped in an ObjC frame or a C++ frame without debug-info). rdar://96236519
2024-06-20	Revert "[lldb][ObjC] Don't query objective-c runtime for decls in C++ ↵	Michael Buch
	contexts (#95963)" This reverts commit dadf960607bb429baebd3f523ce5b93260a154d2. The commit caused `TestEarlyProcessLaunch.py` to fail on the macOS bots.
2024-06-19	[lldb][ObjC] Don't query objective-c runtime for decls in C++ contexts (#95963)	Michael Buch

2024-04-11	[lldb][ClangExpressionParser] Don't by default enable Objecitve-C support ↵	Michael Buch
	when evaluating C++ expressions (#87767) This patch attempts to decouple C++ expression evaluation from Objective-C support. We've previously enabled it by default (if a runtime existed), but that meant we're opting into extra work we only need to do for Objective-C, which complicates/slows down C++ expression evaluation. Of course there's a valid use-case for this, which is calling Objective-C APIs when stopped in C++ frames (which Objective-C++ developers might want to do). In those cases we should really prompt the user to add the `expr --language objc++` flag. To accomodate a likely frequent use-case where a user breaks in a system C++ library (without debug-symbols) but their application is actually an Objective-C app, we allow Objective-C support in C++ expressions if the current frame doesn't have debug-info. This fixes https://github.com/llvm/llvm-project/issues/75443 and allows us to add more `LangOpts.ObjC` guards around the expression evaluator in the future (e.g., we could avoid looking into the Objective-C runtime during C++ expression evaluation, which we currently do unconditionally). Depends on https://github.com/llvm/llvm-project/pull/87657