Fixes for lldb 5.1 #22641
Merged
Fixes for lldb 5.1 #22641
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is failing for me ~10% of the time. It is resulting in spurious PR testing failures. SR-9908 (cherry picked from commit fffbbfe)
If resolving the type of an instance produces a class metadata for which we cannot build a type (for example, a special class like __NSCFNumber, which the ClangImporter does not produce a ClassDecl for), we try the superclass. The caching logic was broken in this case, so subsequent calls would return an empty type. (cherry picked from commit 28f305b)
An Error existential value can directly store a reference to an NSError instance without wrapping it in an Error container. When "projecting" such an existential, the dynamic type is the NSError's isa pointer, and the payload is the address of the instance itself. (cherry picked from commit 76ebaee)
(cherry picked from commit 1dd6765)
LLDB calls getDynamicTypeAndAddressForExistential() on an existential value without knowing if its a class existential or opaque existential. Class existentials return the address of the instance itself here, whereas opaque existentials always returned the address of the payload value. This meant the caller could not usefully operate on the payload value if it was of class type, because there was no way of knowing if the extra dereference had occurred or not. Now, always load the reference if the wrapped type is a class, even if the existential is opaque. Will be tested on the lldb side with another change I'm working on. (cherry picked from commit bd3b451)
The getDynamicTypeAndAddressForExistential() function takes the address of an existential value; so when looking at an Error, this is the address of the reference, not the address of the instance. lldb needs to look at Error instances too, so add a new entry point named getDynamicTypeAndAddressForError() which avoids the extra dereference. This will be tested on the lldb side. (cherry picked from commit 56a74c4)
I need this to reproduce a test failure. (cherry picked from commit c16fed7)
…ntials with named structs (cherry picked from commit 905a6de)
The new trick is that of leavign an unresolved identifier for the expression parser to fill in. <rdar://problem/47982630> (cherry picked from commit 49b2f4e)
|
@slavapestov I'd like to take some of your recent changes to RemoteAST in the initial 5.1 branch. It would make it easier to branch lldb. Does this set of commits make sense in isolation? |
|
@swift-ci test |
|
Build failed |
|
Build failed |
|
Note that this is failing to build in LLDB because PR testing is not setup correctly for 5.1. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pulling some changes needed for recent LLDB fixes onto the initial 5.1 branch