-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
KE2: implement basic usage of properties, variables and flexible types #17884
Conversation
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.
Looks good. I've added a couple of comments.
args | ||
) | ||
} | ||
else -> { |
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.
What are the types that we're handling here? Do we need to add any special handling for enum entries; java/kotlin field access?
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.
Not explored yet; noted a TODO.
when (val resolvedCall = ref.resolveCallTarget()) { | ||
is KaSimpleVariableAccessCall -> { | ||
when (val varSymbol = resolvedCall.symbol) { | ||
is KaPropertySymbol -> { |
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.
Should we make this explicit that we're handling Kotlin properties here? Does the below work for synthetic java properties?
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.
Added a comment clarifying that the path seems to work for both
317fdfc
to
f12818a
Compare
@tamasvajk comments applied; will merge |
Basic implementation of property and variable accesses, and flexible types since they were needed in passing.
Choices for comment:
String!
is extracted asString
; the upper bound would mean we getString?
instead; I don't know from memory if we get flexible types that are more complex than just flexible nullability