D127284 introduced a new language option which is not benign from modules
perspective. Before this patch lldb would set up the compiler invocation and
later enable incremental processing. Post-D127284 this does not work because
the option causes a module hash mismatch for implicit modules.
In addition, D127284 enables parsing statements on the global scope if
incremental processing is on and thus `syntax_error_for_lldb_to_find` was
rightfully not recognized as a declaration and is considered a statement
which produces a slightly different diagnostic.
Thanks to Michael Buch for the help in understanding this issue. This patch
should appease the lldb bots.
More discussion available at: https://reviews.llvm.org/D127284
The test TestObjCDirectMethods loads the Objective C runtime, which
doesn't work well with custom a libcxx, resulting in two copies of the
standard library being loaded at runtime.
Like what was done for `TestObjCExceptions`, this commit forces the
usage of the system's library instead. The minimum required Clang
version is set to the oldest Clang that can compile the libraries
available in the lldb-matrix bots.
Differential Revision: https://reviews.llvm.org/D136600
Since we don't compile with `gmodules` implicitly via
debug-info test replication, we should mark all implicit
`gmodules` tests with the appropriate category so the API
tests get actually run as intended.
Differential Revision: https://reviews.llvm.org/D134574
The coroutine tests require a standard library implementation of
coroutines, which was only made available some time _after_ Clang 13.
The first such Clang tested by the LLDB matrix bot is 15.0.1
The TestObjCExceptions test forces the use of the system's libcxx. For
the lldb matrix bot, the first Clang version compatible with the bot's
libraries is 13.0.
Differential Revision: https://reviews.llvm.org/D134645
This commit improves upon cc0b5ebf7f, 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 commit improves upon cc0b5ebf7f, 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
Remove the test override of `target.prefer-dynamic-value`.
Previously, the lldb default was `no-dynamic-values`. In rG9aa7e8e9ffbe (in
2015), the default was changed to `no-run-target`, but at that time the tests
were changed to be run with `no-dynamic-value`. I don't know the reasons for
not changing the tests, perhaps to avoid determining which tests to change, and
what about them to change.
Because `no-run-target` is the lldb default, I think it makes sense to make it
the test default too. It puts the test config closer to what's used in
practice.
This change removes the `target.prefer-dynamic-value` override, and for those
tests that failed, they have been updated to explicitly use
`no-dynamic-values`. Future changes could update these tests to use dynamic
values too, or they can be left as is to exercise non-dynamic typing.
Differential Revision: https://reviews.llvm.org/D132382
As it exists today, Host::SystemLog is used exclusively for error
reporting. With the introduction of diagnostic events, we have a better
way of reporting those. Instead of printing directly to stderr, these
messages now get printed to the debugger's error stream (when using the
default event handler). Alternatively, if someone is listening for these
events, they can decide how to display them, for example in the context
of an IDE such as Xcode.
This change also means we no longer write these messages to the system
log on Darwin. As far as I know, nobody is relying on this, but I think
this is something we could add to the diagnostic event mechanism.
Differential revision: https://reviews.llvm.org/D128480
Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.
Differential Revision: https://reviews.llvm.org/D128077
Add a function to make it easier to debug a test failure caused by an
unexpected state.
Currently, tests are using assertEqual which results in a cryptic error
message: "AssertionError: 5 != 10". Even when a test provides a message
to make it clear why a particular state is expected, you still have to
figure out which of the two was the expected state, and what the other
value corresponds to.
We have a function in lldbutil that helps you convert the state number
into a user readable string. This patch adds a wrapper around
assertEqual specifically for comparing states and reporting better error
messages.
The aforementioned error message now looks like this: "AssertionError:
stopped (5) != exited (10)". If the user provided a message, that
continues to get printed as well.
Differential revision: https://reviews.llvm.org/D127355
In order to avoid stranding the Objective-C runtime lock, we switched
from objc_copyRealizedClassList to its non locking variant
objc_copyRealizedClassList_nolock. Not taking the lock was relatively
safe because we run this expression on one thread only, but it was still
possible that someone was in the middle of modifying this list while we
were trying to read it. Worst case that would result in a crash in the
inferior without side-effects and we'd unwind and try again later.
With the introduction of macOS Ventura, we can use
objc_getRealizedClassList_trylock instead. It has semantics similar to
objc_copyRealizedClassList_nolock, but instead of not locking at all,
the function returns if the lock is already taken, which avoids the
aforementioned crash without stranding the Objective-C runtime lock.
Because LLDB gets to allocate the underlying memory we also avoid
stranding the malloc lock.
rdar://89373233
Differential revision: https://reviews.llvm.org/D127252
We need to import foundation to get a 'NSLog' declaration when building
against the iOS SDK. This doesn't appear necessary when building against
the macOS SDK, presumable because it gets transitively imported by
objc/NSObject.h
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
Don't try to get a class descriptor for a pointer that doesn't look like
a tagged pointer. Also print addresses as fixed-width hex and update the
test.
- Use formatv to print the addresses.
- Add check for 0x0 which is treated as an invalid address.
- Use a an address that's less likely to be interpreted as a real
tagged pointer.
Improve error handling for the lang objc tagged-pointer info. Rather
than failing silently, report an error if we couldn't convert an
argument to an address or resolve the class descriptor.
(lldb) lang objc tagged-pointer info 0xbb6404c47a587764
error: could not get class descriptor for 0xbb6404c47a587764
(lldb) lang objc tagged-pointer info n1
error: could not convert 'n1' to a valid address
Differential revision: https://reviews.llvm.org/D112945
Currently calling SBType::IsTypeComplete returns true for record types if and
only if the underlying record in our internal Clang AST has a definition.
The function however doesn't actually force the loading of any external
definition from debug info, so it currently can return false even if the type is
actually defined in a program's debug info but LLDB hasn't lazily created the
definition yet.
This patch changes the behaviour to always load the definition first so that
IsTypeComplete now consistently returns true if there is a definition in the
module/target.
The motivation for this patch is twofold:
* The API is now arguably more useful for the user which don't know or care
about the internal lazy loading mechanism of LLDB.
* With D101950 there is no longer a good way to ask a Decl for a definition
without automatically pulling in a definition from the ExternalASTSource. The
current behaviour doesn't seem useful enough to justify the necessary
workarounds to preserve it for a time after D101950.
Note that there was a test that used this API to test lazy loading of debug info
but that has been replaced with TestLazyLoading by now (which just dumps the
internal Clang AST state instead).
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D112615
LLDB evaluates some utility expression to update the Objective-C class list that
ends up calling function such as `free` or `objc_copyRealizedClassList_nolock`.
This adds a test that just tries to define our own bogus version of
`objc_copyRealizedClassList_nolock`. It just tests that LLDB doesn't crash as we
currently don't have a way to tell LLDB to look for the function in a specific
library.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D107778
Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.
We would've upstreamed this earlier but testing it requires
-fno-constant-nsnumber-literals, -fno-constant-nsarray-literals and
-fno-constant-nsdictionary-literals which haven't been upstreamed yet.
As a temporary workaround use the system compiler (xcrun clang) for the
constant variant of the tests.
I'm just upstreaming this. The patch and the tests were all authored by
Fred Riss.
Differential revision: https://reviews.llvm.org/D107660
This reverts commit 34d78b6a67.
This breaks build bots witha missing file:
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:10:10: fatal error: 'objc/runtime.h' file not found
Upstream support for NSConstantArray, NSConstantIntegerNumber,
NSConstant{Float,Double}Number and NSConstantDictionary.
We would've upstreamed this earlier but testing it requires
-fno-constant-nsnumber-literals, -fno-constant-nsarray-literals and
-fno-constant-nsdictionary-literals which haven't been upstreamed yet.
As a temporary workaround use the system compiler (xcrun clang) for the
constant variant of the tests.
I'm just upstreaming this. The patch and the tests were all authored by
Fred Riss.
Differential revision: https://reviews.llvm.org/D107660
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
Use `@import ObjectiveC` instead of `@import Foundation`, as the former is all
that's needed, and results in fewer clang modules being built.
This results in the following clang modules *not* being built for this test.
ApplicationServices
CFNetwork
ColorSync
CoreFoundation
CoreGraphics
CoreServices
CoreText
DiskArbitration
Dispatch
Foundation
IOKit
ImageIO
Security
XPC
_Builtin_intrinsics
launch
libkern
os_object
os_workgroup
Differential Revision: https://reviews.llvm.org/D99859
This is apparently allowed in Objective-C so we should test this in LLDB.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D99513
This is an LLDB test for the ASTImporter crash that got fixed in D99077.
The test is using Clang modules for the properties as it seems the conflicting
names are not actually correctly handled when generating debug information
(only the first property is emitted and the second one is ignored in the current
clang ToT).
Clang emits a warning when accessing an Objective-C getter but not using the result.
This gets triggered when just trying to print a getter value in the expression parser (where
Clang just sees a normal expression like `obj.getter` while parsing).
This patch just disables the warning in the expression parser (similar to what we do with
the C++ equivalent of just accessing a member variable but not doing anything with it).
Reviewed By: kastiglione
Differential Revision: https://reviews.llvm.org/D94307
Convert `assertTrue(a == b)` to `assertEqual(a, b)` to produce better failure messages.
These were mostly done via regex search & replace, with some manual fixes.
Differential Revision: https://reviews.llvm.org/D95813
ObjCBOOLSummaryProvider was incorrectly treating BOOL as unsigned and this is now fixed.
Also adding tests for one bit bit-fields of BOOL and unsigned char.
LLDB is currently always activating C++ when parsing expressions as LLDB itself
is using C++ features when creating the final AST that will be codegen'd
(specifically, references to variables, namespaces and using declarations are
used).
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++. Expressions
referencing those variables fail to parse as LLDB's Clang parser thinks those
identifiers are C++ keywords and not identifiers that may belong to a
declaration.
We can't just disable C++ in the expression parser for those situations as
replacing the functionality of the injected C++ code isn't trivial. So this
patch is just disabling most keywords that are exclusive to C++ in LLDB's Clang
parser when we are in a non-C++ expression. There are a few keywords we can't
disable 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 change
that this will be handled in follow up patches.
Note that this only changes the keyword status of those tokens but this patch
does not remove any C++ functionality from the expression parser. The type
system 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 LLDB
a higher precedence than the macros imported from the Objective-C modules. The
reason for this is that the Objective-C modules in LLDB are actually parsed in
Objective-C++ mode and they end up providing the C++ definitions of certain
system macros (like `NULL` being defined as `nullptr`). So we have to move the
LLDB definition forward and surround the definition from the module with an
`#ifdef` to make sure that we use the correct LLDB definition that doesn't
reference C++ keywords. Or to give an example, this is how the expression source
code 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://10356912
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D82770
Display null pointer as `nullptr`, `nil` and `NULL` for C++,
Objective-C/Objective-C++ and C respectively. The original motivation
for this patch was to display a null std::string pointer as nullptr
instead of "", but the fix seemed generic enough to be done for all
summary providers.
Differential revision: https://reviews.llvm.org/D77153
Make category-specifying files visible. There is really no good reason
to keep them hidden, and having them visible increases the chances
that someone will actually spot them.
Differential Revision: https://reviews.llvm.org/D91065
