RemoteAST fixes #22502
Merged
RemoteAST fixes #22502
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
slavapestov
force-pushed
the
remote-ast-fixes
branch
from
b7d31e4 to
d21de1c
Compare
Contributor
Author
|
@swift-ci Please smoke test |
slavapestov
requested review from
dcci and
rjmccall
and removed request for
rjmccall
rjmccall
reviewed
Feb 11, 2019
Contributor
There was a problem hiding this comment.
Consider just making a struct, especially since this type is used multiple places throughout the reader.
lib/RemoteAST/RemoteAST.cpp
Outdated
Contributor
There was a problem hiding this comment.
The pattern was that all of these were Result-ified.
Contributor
Author
|
@swift-ci Please smoke test |
slavapestov
force-pushed
the
remote-ast-fixes
branch
from
14e36c3 to
40a9880
Compare
Contributor
Author
|
@swift-ci Please smoke test |
slavapestov
force-pushed
the
remote-ast-fixes
branch
from
40a9880 to
8f56bce
Compare
Contributor
Author
|
apple/swift-lldb#1287 |
Contributor
Author
|
apple/swift-lldb#1287 |
Contributor
Author
|
Looks like this breaks LLDB without my larger set of LDLB changes. I'm breaking out #22534 to fix the tagged pointer issue. |
slavapestov
force-pushed
the
remote-ast-fixes
branch
from
8f56bce to
1c72e05
Compare
…n up the code flow
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.
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.
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.
…ntials with named structs
slavapestov
force-pushed
the
remote-ast-fixes
branch
from
1c72e05 to
905a6de
Compare
Contributor
Author
|
apple/swift-lldb#1287 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
In the service of apple/swift-lldb#1286. Replacing lldb's existing existential projection code path with RemoteAST exposed some limitations in the latter.