Skip to content

[lldb] Implement TypeSystemSwiftTypeRef::IsMeaninglessWithoutDynamicResolution #2191

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

Conversation

kastiglione
Copy link

Implement TypeSystemSwiftTypeRef::IsMeaninglessWithoutDynamicResolution.

rdar://68171389

@kastiglione
Copy link
Author

Running the tests results in one SwiftASTContext cross validation assertion, for the symbol $sxIgr_D:

% swift demangle -expand sxIgr_D
Demangling for $sxIgr_D
kind=Global
  kind=TypeMangling
    kind=Type
      kind=ImplFunctionType
        kind=ImplConvention, text="@callee_guaranteed"
        kind=ImplResult
          kind=ImplConvention, text="@out"
          kind=Type
            kind=DependentGenericParamType
              kind=Index, index=0
              kind=Index, index=0
$sxIgr_D ---> @callee_guaranteed () -> (@out A)

It seems something about this tree pattern will need to be special cased.

@kastiglione kastiglione marked this pull request as draft December 5, 2020 06:02
@kastiglione
Copy link
Author

kastiglione commented Dec 7, 2020

I had a new thought, maybe this is a bug and the existing implementation is incorrect? Should IsMeaninglessWithoutDynamicResolution return true, or false, for the type @callee_guaranteed () -> (@out A)?

@adrian-prantl
Copy link

This is a generic type, so naively one would think it is dynamic. However, since it is a function type, we don't actually have any means to bind it like we do for other types, since it the binding would only happen at one specific call site.

I think it would be most intuitive if both implementations returned false. Probably by special-casing function types.

@kastiglione
Copy link
Author

Sounds reasonable.

Probably by special-casing function types.

Do you have any thoughts on how to narrow which function types? There are a number of node kinds named with "FunctionType":

% rg FunctionType include/swift/Demangling/DemangleNodes.def
72:NODE(DifferentiableFunctionType)
73:NODE(EscapingDifferentiableFunctionType)
74:NODE(LinearFunctionType)
75:NODE(EscapingLinearFunctionType)
87:NODE(NoEscapeFunctionType)
99:NODE(FunctionType)
126:NODE(ImplFunctionType)
216:NODE(ThinFunctionType)
233:NODE(UncurriedFunctionType)

@adrian-prantl
Copy link

I would just defer this question to TypeSystem::IsFunctionType() and worry about whether it is implemented correctly when/if that becomes a problem.

@kastiglione
Copy link
Author

I see a IsFunctionType predicate already exists. It checks for only FunctionType and ImplFunctionType. I'll use that.

@kastiglione kastiglione marked this pull request as ready for review December 7, 2020 18:04
Comment on lines 2308 to 2309
auto *node = DemangleCanonicalType(dem, type);
if (IsFunctionType(type, nullptr))
Copy link
Author

@kastiglione kastiglione Dec 7, 2020

Choose a reason for hiding this comment

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

note that this will demangle the type twice.

Choose a reason for hiding this comment

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

That's ok, we will do an NFC performance pass once the implementation is complete. For now let's focus on clarity!

@kastiglione
Copy link
Author

@swift-ci test

@kastiglione
Copy link
Author

@swift-ci test

@kastiglione
Copy link
Author

@swift-ci test

@kastiglione kastiglione merged commit 006268a into swift/main Dec 7, 2020
@kastiglione kastiglione deleted the lldb-Implement-TypeSystemSwiftTypeRef-IsMeaninglessWithoutDynamicResolution branch December 7, 2020 23:41
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