added getName method in SBModule.h and .cpp in order to get the name of the module from m_object_name. --------- Co-authored-by: Bar Soloveychik <barsolo@fb.com>
Parsing of '::' scopes in TypeQuery was very naive and failed for names with '::''s in template arguments. Interestingly, one of the functions it was calling (Type::GetTypeScopeAndBasename) was already doing the same thing, and getting it (mostly (*)) right. This refactors the function so that it can return the scope results, fixing the parsing of names like std::vector<int, std::allocator<int>>::iterator. Two callers of GetTypeScopeAndBasename are deleted as the functions are not used (I presume they stopped being used once we started pruning type search results more eagerly). (*) This implementation is still not correct when one takes c++ operators into account -- e.g., something like `X<&A::operator<>::T` is a legitimate type name. We do have an implementation that is able to handle names like these (CPlusPlusLanguage::MethodName), but using it is not trivial, because it is hidden in a language plugin and specific to method name parsing. --------- Co-authored-by: Michael Buch <michaelbuch12@gmail.com>
This uses [teyit](https://pypi.org/project/teyit/) to modernize asserts, as recommended by the [unittest release notes](https://docs.python.org/3.12/whatsnew/3.12.html#id3). For example, `assertTrue(a == b)` is replaced with `assertEqual(a, b)`. This produces better error messages, e.g. `error: unexpectedly found 1 and 2 to be different` instead of `error: False`.
This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black` (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run `git checkout --ours <yourfile>` and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460
This commit improves upon cc0b5ebf7fc8, which added support for specifying which libcxx to use when testing LLDB. That patch honored requests by tests that had `USE_LIBCPP=1` defined in their makefiles. Now, we also use a non-default libcxx if all conditions below are true: 1. The test is not explicitly requesting the use of libstdcpp (USE_LIBSTDCPP=1). 2. The test is not explicitly requesting the use of the system's library (USE_SYSTEM_STDLIB=1). 3. A path to libcxx was either provided by the user through CMake flags or libcxx was built together with LLDB. Condition (2) is new and introduced in this patch in order to support tests that are either: * Cross-platform (such as API/macosx/macCatalyst and API/tools/lldb-server). The just-built libcxx is usually not built for platforms other than the host's. * Cross-language (such as API/lang/objc/exceptions). In this case, the Objective C runtime throws an exceptions that always goes through the system's libcxx, instead of the just built libcxx. Fixing this would require either changing the install-name of the just built libcxx in Mac systems, or tuning the DYLD_LIBRARY_PATH variable at runtime. Some other tests exposes limitations of LLDB when running with a debug standard library. TestDbgInfoContentForwardLists had an assertion removed, as it was checking for buggy LLDB behavior (which now crashes). TestFixIts had a variable renamed, as the old name clashes with a standard library name when debug info is present. This is a known issue: https://github.com/llvm/llvm-project/issues/34391. For `TestSBModule`, the way the "main" module is found was changed to look for the "a.out" module, instead of relying on the index being 0. In some systems, the index 0 is dyld when a custom standard library is used. Differential Revision: https://reviews.llvm.org/D132940
This reverts commit c38eeecbc7d929c9601f2189214a7a90d3982a47.
This commit improves upon cc0b5ebf7fc8, which added support for specifying which libcxx to use when testing LLDB. That patch honored requests by tests that had `USE_LIBCPP=1` defined in their makefiles. Now, we also use a non-default libcxx if all conditions below are true: 1. The test is not explicitly requesting the use of libstdcpp (USE_LIBSTDCPP=1). 2. The test is not explicitly requesting the use of the system's library (USE_SYSTEM_STDLIB=1). 3. A path to libcxx was either provided by the user through CMake flags or libcxx was built together with LLDB. Condition (2) is new and introduced in this patch in order to support tests that are either: * Cross-platform (such as API/macosx/macCatalyst and API/tools/lldb-server). The just-built libcxx is usually not built for platforms other than the host's. * Cross-language (such as API/lang/objc/exceptions). In this case, the Objective C runtime throws an exceptions that always goes through the system's libcxx, instead of the just built libcxx. Fixing this would require either changing the install-name of the just built libcxx in Mac systems, or tuning the DYLD_LIBRARY_PATH variable at runtime. Some other tests exposes limitations of LLDB when running with a debug standard library. TestDbgInfoContentForwardLists had an assertion removed, as it was checking for buggy LLDB behavior (which now crashes). TestFixIts had a variable renamed, as the old name clashes with a standard library name when debug info is present. This is a known issue: https://github.com/llvm/llvm-project/issues/34391. For `TestSBModule`, the way the "main" module is found was changed to look for the "a.out" module, instead of relying on the index being 0. In some systems, the index 0 is dyld when a custom standard library is used. Differential Revision: https://reviews.llvm.org/D132940
Eliminate boilerplate of having each test manually assign to `mydir` by calling `compute_mydir` in lldbtest.py. Differential Revision: https://reviews.llvm.org/D128077
Skip a bunch of tests that don't really make sense to run remotely.
Replace forms of `assertTrue(err.Success())` with `assertSuccess(err)` (added in D82759). * `assertSuccess` prints out the error's message * `assertSuccess` expresses explicit higher level semantics, both to the reader and for test failure output * `assertSuccess` seems not to be well known, using it where possible will help spread knowledge * `assertSuccess` statements are more succinct Differential Revision: https://reviews.llvm.org/D119616