Skip to content

[lldb] Implement TypeSystemSwiftTypeRef::IsPossibleDynamicType #2232

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.

Sign up for GitHub

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 8 commits into from
Dec 14, 2020
Merged

[lldb] Implement TypeSystemSwiftTypeRef::IsPossibleDynamicType #2232

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
cd9a7fc
[lldb] Implement TypeSystemSwiftTypeRef::IsPossibleDynamicType
kastiglione Dec 11, 2020
6ef3f67
use precise/non-ambiguous type name instead of auto
kastiglione Dec 12, 2020
4beccfb
add ProtocolListWithAnyObject
kastiglione Dec 12, 2020
1122b69
handle TypeAlias to Swift.AnyObject
kastiglione Dec 12, 2020
e97417a
add ExistentialMetatype
kastiglione Dec 12, 2020
26fa282
resolve type aliases
kastiglione Dec 12, 2020
8552c56
add special case handling of NSNotificationName
kastiglione Dec 14, 2020
f8d2fb2
use std::get<T>
kastiglione Dec 14, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 53 additions & 2 deletions lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwiftTypeRef.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1764,13 +1764,64 @@ bool TypeSystemSwiftTypeRef::IsFunctionPointerType(
VALIDATE_AND_RETURN(impl, IsFunctionPointerType, type,
(ReconstructType(type)));
}

bool TypeSystemSwiftTypeRef::IsPossibleDynamicType(opaque_compiler_type_t type,
CompilerType *target_type,
bool check_cplusplus,
bool check_objc) {
return m_swift_ast_context->IsPossibleDynamicType(
ReconstructType(type), target_type, check_cplusplus, check_objc);
if (target_type)
target_type->Clear();
Copy link

Choose a reason for hiding this comment

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

Side note: This is a good example of some of LLDB's less than great APIs. I'm sure we're not very consistent in whether this should get cleared or not in the failure case...

Copy link
Author

Choose a reason for hiding this comment

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

In SwiftASTContext it is cleared unconditionally.


if (!type)
return false;

// This is a discrepancy with `SwiftASTContext`. The `impl` below correctly
// returns true, but `VALIDATE_AND_RETURN` will assert. This hardcoded
// handling of `__C.NSNotificationName` can be removed when the
// `VALIDATE_AND_RETURN` is removed.
if (GetMangledTypeName(type) == "$sSo18NSNotificationNameaD")
return true;

auto impl = [&]() {
using namespace swift::Demangle;
Demangler dem;
auto *node = DemangleCanonicalType(dem, type);
if (!node)
return false;

if (node->getKind() == Node::Kind::TypeAlias) {
auto resolved = ResolveTypeAlias(m_swift_ast_context, dem, node);
if (auto *n = std::get<swift::Demangle::NodePointer>(resolved))
node = n;
}

switch (node->getKind()) {
case Node::Kind::Class:
case Node::Kind::BoundGenericClass:
case Node::Kind::Protocol:
case Node::Kind::ProtocolList:
case Node::Kind::ProtocolListWithClass:
case Node::Kind::ProtocolListWithAnyObject:
case Node::Kind::ExistentialMetatype:
case Node::Kind::DynamicSelf:
return true;
case Node::Kind::BuiltinTypeName: {
if (!node->hasText())
return false;
Copy link

Choose a reason for hiding this comment

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

Side note: And here we should have an error channel ...

Copy link
Author

Choose a reason for hiding this comment

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

by changing the return type of this function? or by logging?

Copy link

Choose a reason for hiding this comment

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

This was just me rambling — you didn't design this API :-)

It would be best if all CompilerType operations had a way to signal an error case, so we aren't silently ignoring errors. Either by returning Optionals, Expected, and for the functions that return a new type, potentially even a special Error type in a special Error TypeSystem, so the operations still compose nicely.

Copy link
Author

Choose a reason for hiding this comment

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

I totally agree.

StringRef name = node->getText();
return name == swift::BUILTIN_TYPE_NAME_RAWPOINTER ||
name == swift::BUILTIN_TYPE_NAME_NATIVEOBJECT ||
name == swift::BUILTIN_TYPE_NAME_BRIDGEOBJECT;
}
default:
return ContainsGenericTypeParameter(node);
}
};
VALIDATE_AND_RETURN(
impl, IsPossibleDynamicType, type,
(ReconstructType(type), nullptr, check_cplusplus, check_objc));
}

bool TypeSystemSwiftTypeRef::IsPointerType(opaque_compiler_type_t type,
CompilerType *pointee_type) {
auto impl = [&]() {
Expand Down