Skip to content

Revert "Restrict RemoteASTTypeBuilder::findModule() to the list of lo… #17384

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 21, 2018

Conversation

adrian-prantl
Copy link
Contributor

…aded modules."

This reverts commit 30ea6ec.

LLDB is smarter than I expected it to be. One of the failing tests
"metatype" is very short and does not import any modules
whatsoever. It turns out that swift_runtime->GetMetadataPromise()
creates a RemoteAST with the Scratch AST context. LLDB does not
pre-import any modules for the scratch AST context.

Using the scratch context is actually the behavior we'd want for all
kinds of dynamic type resolution, since we need to handle the
worst-case dynamic type (a tuple of existentials that each originate
from different modules that don't import each other) gracefully.

So what I'm going to try next is revert the RemoteAST change and try
to get the dynamic type resolution in this case to use the scratch AST
context instead of the per-module AST context.

I'm still going to add a flag to RemoteAST to indicate wether
importing other modules should be allowed or not and set that
according to whether this is a module context or the scratch context.

rdar://problem/40950542

…aded modules."

This reverts commit 30ea6ec.

LLDB is smarter than I expected it to be.  One of the failing tests
"metatype" is very short and does not import any modules
whatsoever. It turns out that swift_runtime->GetMetadataPromise()
creates a RemoteAST with the Scratch AST context. LLDB does not
pre-import any modules for the scratch AST context.

Using the scratch context is actually the behavior we'd want for all
kinds of dynamic type resolution, since we need to handle the
worst-case dynamic type (a tuple of existentials that each originate
from different modules that don't import each other) gracefully.

So what I'm going to try next is revert the RemoteAST change and try
to get the dynamic type resolution in this case to use the scratch AST
context instead of the per-module AST context.

I'm still going to add a flag to RemoteAST to indicate wether
importing other modules should be allowed or not and set that
according to whether this is a module context or the scratch context.
@adrian-prantl
Copy link
Contributor Author

test with apple/swift-lldb#706
@swift-ci test

@adrian-prantl adrian-prantl merged commit a59e909 into swiftlang:master Jun 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant