-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
base: ke2
Are you sure you want to change the base?
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?
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?
is KaSimpleVariableAccess.Write -> Pair(varSymbol.setter, listOf(access.value)) | ||
} | ||
|
||
val qualifier: KtExpression? = (ref.parent as? KtDotQualifiedExpression)?.receiverExpression |
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.
After #17881 is merged, I think KtDotQualifiedExpression
needs to be changed to KtQualifiedExpression
.
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