-
Notifications
You must be signed in to change notification settings - Fork 351
[lldb] Push down instantiation of SwiftASTContext on tss-TypeRef #3688
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
base: stable/20210726
Are you sure you want to change the base?
[lldb] Push down instantiation of SwiftASTContext on tss-TypeRef #3688
Conversation
|
@swift-ci test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC, I renamed this to target_holder because in the end we wanted to read the Target* from it. If that's true, maybe this should be a std::function<Target *()> target_provider?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, that sounds better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Edit: std::function<TargetWP()>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's one situation where we need the ASTContext, so I think keeping it returning a SwiftASTContext is probably better.
} Impl(swift_ast_context ? swift_ast_context->GetASTContext() : nullptr);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's in GetClangTypeNode(CompilerType clang_type, swift::Demangle::Demangler &dem, SwiftASTContext *swift_ast_context) which doesn't call the argument target_holder. Maybe those two use-cases can be treated separately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uh.. it's unfortunate that we need this there unconditionally. I guess the next task will be to see if we can factor out AST->getSwiftName() to not need a full SwiftASTContext initialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's better to keep it like this for now, as we're threading to both places from the same intermediary functions, and I think it'd be more confusing to treat them as separate (for now). If we factor out AST->getSwiftName() then we'll probably have to separate the cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is either of GetSwiftASTContextLazy() or GetLazySwiftASTContext() a more descriptive name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it looks like we really just want a TargetWP here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do go with the "lazy" naming scheme, we could call swift_ast_context_provider lazy_swift_ast_context
adrian-prantl
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a few naming suggestions inside, but otherwise this looks good!
18830ba to
8f891eb
Compare
|
@swift-ci test |
|
@swift-ci test Linux |
No description provided.