[lldb] Fix macOS Ventura version number checksUnlike Python 2 which reports 10.16 on any recent macOS, Python 3correctly reports Ventura as macOS 13.
[lldb] XFAIL TestObjCXXBridgedPO on macOS VenturaTestObjCXXBridgedPO is broken on macOS Ventura (but not on macOSMonterey). I took a look but it doesn't seem trivial. I'm XFAILing thetest until A
[lldb] XFAIL TestObjCXXBridgedPO on macOS VenturaTestObjCXXBridgedPO is broken on macOS Ventura (but not on macOSMonterey). I took a look but it doesn't seem trivial. I'm XFAILing thetest until Adrian, who wrote the test, can take a look.rdar://96224141
show more ...
[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://r
[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://reviews.llvm.org/D128077
[lldb] Add a test for potentially conflicting names for the Objective-C class update utility expressionWe recently had an issue where a user declared a `Class::free` function whichthen got picked
[lldb] Add a test for potentially conflicting names for the Objective-C class update utility expressionWe recently had an issue where a user declared a `Class::free` function whichthen got picked up by accident by the expression evaluator when calling`::free`. This was due to a too lax filter in the DWARFIndex (which was fixed byhttps://reviews.llvm.org/D73191 ). This broke the Objective-C utility expressionthat is trying to update the Objective-C class list (which is calling `:;free`).This adds a regression test for situations where we have a bunch of functionsdefined that share the name of the global functions that this utility functioncalls. None of them are actually conflicting with the global functions we aretrying to call (they are all in namespaces, objects or classes).Reviewed By: JDevlieghereDifferential Revision: https://reviews.llvm.org/D107776
[lldb] Replace unneeded use of Foundation with ObjectiveC in tests (NFC)When referencing `NSObject`, it's enough to import `objc/NSObject.h`. Importing `Foundation` is unnecessary in these cases.
[lldb] Replace unneeded use of Foundation with ObjectiveC in tests (NFC)When referencing `NSObject`, it's enough to import `objc/NSObject.h`. Importing `Foundation` is unnecessary in these cases.Differential Revision: https://reviews.llvm.org/D99867
[lldb] Add support for using variables with C++ keywords names in non-C++ expressionsLLDB is currently always activating C++ when parsing expressions as LLDB itselfis using C++ features when creat
[lldb] Add support for using variables with C++ keywords names in non-C++ expressionsLLDB is currently always activating C++ when parsing expressions as LLDB itselfis using C++ features when creating the final AST that will be codegen'd(specifically, references to variables, namespaces and using declarations areused).This is causing problems for users that have variables in non-C++ programs (e.g.plain C or Objective-C) that have names which are keywords in C++. Expressionsreferencing those variables fail to parse as LLDB's Clang parser thinks thoseidentifiers are C++ keywords and not identifiers that may belong to adeclaration.We can't just disable C++ in the expression parser for those situations asreplacing the functionality of the injected C++ code isn't trivial. So thispatch is just disabling most keywords that are exclusive to C++ in LLDB's Clangparser when we are in a non-C++ expression. There are a few keywords we can'tdisable for now:* `using` as that's currently used in some situations to inject variables into the expression function.* `__null` as that's used by LLDB to define `NULL`/`Nil`/`nil`.Getting rid of these last two keywords is possible but is a large enough changethat this will be handled in follow up patches.Note that this only changes the keyword status of those tokens but this patchdoes not remove any C++ functionality from the expression parser. The typesystem still follows C++ rules and so does the rest of the expression parser.There is another small change that gives the hardcoded macro definitions in LLDBa higher precedence than the macros imported from the Objective-C modules. Thereason for this is that the Objective-C modules in LLDB are actually parsed inObjective-C++ mode and they end up providing the C++ definitions of certainsystem macros (like `NULL` being defined as `nullptr`). So we have to move theLLDB definition forward and surround the definition from the module with an`#ifdef` to make sure that we use the correct LLDB definition that doesn'treference C++ keywords. Or to give an example, this is how the expression sourcecode changes:Before:``` #define NULL (nullptr) // injected module definition #ifndef NULL #define NULL (__null) // hardcoded LLDB definition #endif```After:``` #ifndef NULL #define NULL (__null) // hardcoded LLDB definition #endif #ifndef NULL #define NULL (nullptr) // injected module definition #endif```Fixes rdar://10356912Reviewed By: shafikDifferential Revision: https://reviews.llvm.org/D82770
[lldb/DataFormatters] Display null C++ pointers as nullptrDisplay null pointer as `nullptr`, `nil` and `NULL` for C++,Objective-C/Objective-C++ and C respectively. The original motivationfor this
[lldb/DataFormatters] Display null C++ pointers as nullptrDisplay null pointer as `nullptr`, `nil` and `NULL` for C++,Objective-C/Objective-C++ and C respectively. The original motivationfor this patch was to display a null std::string pointer as nullptrinstead of "", but the fix seemed generic enough to be done for allsummary providers.Differential revision: https://reviews.llvm.org/D77153
[lldb] [test] Rename '.categories' to 'categories'Make category-specifying files visible. There is really no good reasonto keep them hidden, and having them visible increases the chancesthat som
[lldb] [test] Rename '.categories' to 'categories'Make category-specifying files visible. There is really no good reasonto keep them hidden, and having them visible increases the chancesthat someone will actually spot them.Differential Revision: https://reviews.llvm.org/D91065
[lldb] [test] Skip ObjC-based tests via 'objc' categoryReplace the plethora of ObjC-implied 'skipUnlessDarwin' decoratorswith marking tests as 'objc' category (whenever missing), and skip allObjC
[lldb] [test] Skip ObjC-based tests via 'objc' categoryReplace the plethora of ObjC-implied 'skipUnlessDarwin' decoratorswith marking tests as 'objc' category (whenever missing), and skip allObjC tests on non-Darwin platforms. I have used '.categories' filewherever it was present already or all (>1) tests were relying on ObjC,and explicit add_test_categories() where there was only one test.Differential Revision: https://reviews.llvm.org/D91056
[lldb] [test] Use skipUnlessDarwin for tests specific to DarwinUse skipUnlessDarwin decorator for tests that are specific to Darwin,instead of skipIf... for all other platforms. This should make
[lldb] [test] Use skipUnlessDarwin for tests specific to DarwinUse skipUnlessDarwin decorator for tests that are specific to Darwin,instead of skipIf... for all other platforms. This should make it clearthat these tests are not supposed to work elsewhere. It will also makethese tests stop repeatedly popping up while I look for tests that couldbe fixed on the platform in question.Differential Revision: https://reviews.llvm.org/D91003
Repair support for launching ios/tv/watch simulator binaries through platformand delete a bunch (but not all) redundant code. If you compare the remaining implementations of Platform*Simulator.cpp,
Repair support for launching ios/tv/watch simulator binaries through platformand delete a bunch (but not all) redundant code. If you compare the remaining implementations of Platform*Simulator.cpp, there is still an obvious leftover cleanup task.Specifically, this patch- removes SDK initialization from dotest (there is equivalent but more complete code in Makefile.rules)- make Platform*Simulator inherit the generic implementation of PlatformAppleSimulator (more can be done here)- simplify the platform logic in Makefile.rules- replace the custom SDK finding logic in Platform*Simulator with XcodeSDK- adds a test for each supported simulatorDifferential Revision: https://reviews.llvm.org/D81980
[lldb][test] Remove symlink for API tests.Summary: Moves lldbsuite tests to lldb/test/API.This is a largely mechanical change, moved with the following steps:```rm lldb/test/API/testcasesmkdi
[lldb][test] Remove symlink for API tests.Summary: Moves lldbsuite tests to lldb/test/API.This is a largely mechanical change, moved with the following steps:```rm lldb/test/API/testcasesmkdir -p lldb/test/API/{test_runner/test,tools/lldb-{server,vscode}}mv lldb/packages/Python/lldbsuite/test/test_runner/test lldb/test/API/test_runnerfor d in $(find lldb/packages/Python/lldbsuite/test/* -maxdepth 0 -type d | egrep -v "make|plugins|test_runner|tools"); do mv $d lldb/test/API; donefor d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-vscode -maxdepth 1 -mindepth 1 | grep -v ".py"); do mv $d lldb/test/API/tools/lldb-vscode; donefor d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-server -maxdepth 1 -mindepth 1 | egrep -v "gdbremote_testcase.py|lldbgdbserverutils.py|socket_packet_pump.py"); do mv $d lldb/test/API/tools/lldb-server; done```lldb/packages/Python/lldbsuite/__init__.py and lldb/test/API/lit.cfg.py were also updated with the new directory structure.Reviewers: labath, JDevlieghereTags: #lldbDifferential Revision: https://reviews.llvm.org/D71151