Skip to content

Implemement TypeSystemSwiftTypeRef::GetBitSize() (NFC) #1636

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 7 commits into from
Sep 8, 2020

Conversation

adrian-prantl
Copy link

In order to implement GetBitSize, this patch also adds an initial
TypeRef-based implementation of
SwiftLanguageRuntimeImpl::DoArchetypeBinding(). To make
SwiftLanguageRuntimeImpl::GetTypeInfo() work with TypeRefs of
ClangImported non-Objective-C types, a new callback is added to
swift::reflection::MemoryReader, which allos LLDB to provide the
swift::reflection::TypeInfo for a Clang type based on debug
information.

rdar://problem/55412920

Needs swiftlang/swift#33417

@adrian-prantl adrian-prantl requested review from vedantk and dcci August 12, 2020 00:48
@adrian-prantl adrian-prantl changed the title Implemement TypeSystemSwiftTypeRef::GetBitSize() (NFC) [WIP] Implemement TypeSystemSwiftTypeRef::GetBitSize() (NFC) Aug 12, 2020
@adrian-prantl
Copy link
Author

This is not yet ready, a few tests are still failing. Just trying to get early feedback for swiftlang/swift#33417

@adrian-prantl adrian-prantl force-pushed the 55412920 branch 3 times, most recently from 9996dd0 to 34ec1a3 Compare August 14, 2020 21:34
@adrian-prantl adrian-prantl force-pushed the 55412920 branch 2 times, most recently from ac8941d to f26b688 Compare August 22, 2020 00:56
@adrian-prantl
Copy link
Author

@kastiglione This is my work-in-progress for the GetBitSize() implementation. The patch is rather larger because it depends on an implementation of DoArchetypBinding(), which makes up the bulk the wor.

@adrian-prantl adrian-prantl force-pushed the 55412920 branch 3 times, most recently from c37068b to 6814c3f Compare August 28, 2020 00:59
@adrian-prantl adrian-prantl changed the title [WIP] Implemement TypeSystemSwiftTypeRef::GetBitSize() (NFC) Implemement TypeSystemSwiftTypeRef::GetBitSize() (NFC) Aug 28, 2020
@adrian-prantl
Copy link
Author

This is good to go now.

@adrian-prantl
Copy link
Author

@swift-ci test

@adrian-prantl
Copy link
Author

test with swiftlang/swift#33417
@swift-ci test

1 similar comment
@adrian-prantl
Copy link
Author

test with swiftlang/swift#33417
@swift-ci test

Copy link

@kastiglione kastiglione left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a first pass of reading and questions, there's a lot here (for me anyway), I'll do a follow up read. Sorry for some minor comments.

@@ -114,6 +134,21 @@ class SwiftLanguageRuntimeImpl {
bool IsABIStable();

protected:
/// Use the reflection context to build a TypeRef object.
///
///\param module can be used to specify a module to look up DWARF

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this correct formatting, or will it cause rendering issues?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a typo!

return nullptr;
swift::Demangle::NodePointer node =
TypeSystemSwiftTypeRef::GetCanonicalDemangleTree(
module ? module : ts->GetModule(), Dem, mangled_name.GetStringRef());

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
module ? module : ts->GetModule(), Dem, mangled_name.GetStringRef());
module ?: ts->GetModule(), Dem, mangled_name.GetStringRef());

Comment on lines +1980 to +1998
// but all the other functions currently get this wrong, too!
m_process.GetTarget().CalculateExecutionContext(exe_ctx);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

am I understanding right that this isn't using frame, to match other places calling it wrong?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I made a note in rdar://problem/67587895 Locking the wrong scratch context in most places in SwiftLanguageRuntimeDynamicTypeResolution.cpp to fix this in a separate commit.


std::string SwiftASTContext::ImportName(const clang::NamedDecl *clang_decl) {
if (auto clang_importer = GetClangImporter()) {
// FIMXE: It's not clear why this special case is necessary.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to self: I forgot about this. I meant to check this before uploading.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's no longer necessary.

@adrian-prantl adrian-prantl force-pushed the 55412920 branch 6 times, most recently from e589cb0 to 4f33869 Compare September 1, 2020 21:11
@adrian-prantl
Copy link
Author

test with swiftlang/swift#33417
@swift-ci test

@adrian-prantl adrian-prantl changed the base branch from swift/master-rebranch to swift/master September 3, 2020 19:55
In order to implement GetBitSize, this patch also adds an initial
TypeRef-based implementation of
SwiftLanguageRuntimeImpl::DoArchetypeBinding(). To make
SwiftLanguageRuntimeImpl::GetTypeInfo() work with TypeRefs of
ClangImported non-Objective-C types, a new callback is added to
swift::reflection::MemoryReader, which allos LLDB to provide the
swift::reflection::TypeInfo for a Clang type based on debug
information.

<rdar://problem/55412920>
The SwiftOptionSet data formatter still reconstructs types after ths
patch because there is leftover work in ClangImporter to separate out
name importing.

<rdar://problem/67709905>
@adrian-prantl
Copy link
Author

test with swiftlang/swift#33417
@swift-ci smoke test

1 similar comment
@adrian-prantl
Copy link
Author

test with swiftlang/swift#33417
@swift-ci smoke test

@adrian-prantl
Copy link
Author

test with swiftlang/swift#33417
@swift-ci test

@adrian-prantl
Copy link
Author

test with swiftlang/swift#33417
@swift-ci test

module that does not have two different implementations that vary
based off an opaque #define.
@adrian-prantl
Copy link
Author

test with swiftlang/swift#33417
@swift-ci test

@adrian-prantl
Copy link
Author

test with swiftlang/swift#33417
@swift-ci test

@adrian-prantl
Copy link
Author

test with swiftlang/swift#33417
@swift-ci test

@adrian-prantl adrian-prantl merged commit b5bedc4 into swiftlang:swift/master Sep 8, 2020
@kastiglione
Copy link

Did this not get picked into master-next?

@adrian-prantl
Copy link
Author

adrian-prantl commented Sep 10, 2020 via email

@kastiglione
Copy link

Do we prefer to push directly instead of using a PR?

@@ -1587,7 +1643,64 @@ TypeSystemSwiftTypeRef::GetPointerType(opaque_compiler_type_t type) {
llvm::Optional<uint64_t>
TypeSystemSwiftTypeRef::GetBitSize(opaque_compiler_type_t type,
ExecutionContextScope *exe_scope) {
return m_swift_ast_context->GetBitSize(ReconstructType(type), exe_scope);
auto impl = [&]() -> llvm::Optional<uint64_t> {
// Bug-for-bug compatibility. See comment in SwiftASTContext::GetBitSize().

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How come this implementation is so much different from master-next? dab2fc6#diff-4f052b540e66838ef123c3a839bacf1cR1617-R1629

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example GetAsClangTypeOrNull exists in this PR but not in the master-next version?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for catching this! I mush have cherry-picked an older version of the commit. Wow.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm.. no. git diff origin/swift/master doesn't show a difference. Is it possible that this is the state of one of the earlier commits in the PR and not the final one?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the reason I noticed this is because when I cherry picked #1779, there were changes to GetAsClangTypeOrNull that did not exist at all on swift/master-next.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am confused 🤔

Copy link

@kastiglione kastiglione Sep 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems I have done something slightly wrong in my cherry-pick in #1779.

@adrian-prantl
Copy link
Author

Do we prefer to push directly instead of using a PR?

Either way fine — I usually create two PRs so I can merge them at the same time once the testing for the master one has succeeded. This was an exception.

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.

2 participants