-
Notifications
You must be signed in to change notification settings - Fork 341
[lldb] Allow SwiftASTContext fallbacks for types from expressions #10059
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
[lldb] Allow SwiftASTContext fallbacks for types from expressions #10059
Conversation
3b7b4dd
to
96a5219
Compare
@swift-ci test |
Hmm, could you give an example of something that an expression returns that is not anchored by a variable? |
Totally! This is from TestSwiftExpr.py:
There is nothing holding on to |
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 with this if we legitimately can't use DWARF and reflection metadata for certain use-cases.
You mean the type alias foo right? With the expression log enabled:
Is it because |
Good question! I only looked at the expression log to see what DITypes are generated and there was no DILocalVariable for the result:
|
|
Generally, it would be feasible to rely on DWARF and reflectio metadata for JIT-compiled images, but in practice, not everything that an expression returns may be anchored by a variable, which makes having debug info for expression-defined types hit and miss. If an expression type is involved, LLDB will have done the costly SwiftASTContext initialization already, so there isn't much saved by avoiding the fallback in this case.
96a5219
to
ce4b4ee
Compare
@swift-ci test |
Generally, it would be feasible to rely on DWARF and reflectio metadata for JIT-compiled images, but in practice, not everything that an expression returns may be anchored by a variable, which makes having debug info for expression-defined types hit and miss. If an expression type is involved, LLDB will have done the costly SwiftASTContext initialization already, so there isn't much saved by avoiding the fallback in this case.