Skip to content
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

resolveJavaDeclaration fails if the java method starts with get or set #200

Closed
yigit opened this issue Dec 21, 2020 · 1 comment · Fixed by #201
Closed

resolveJavaDeclaration fails if the java method starts with get or set #200

yigit opened this issue Dec 21, 2020 · 1 comment · Fixed by #201

Comments

@yigit
Copy link
Collaborator

yigit commented Dec 21, 2020

For the followign input:

// FILE: JavaIntefaceWithVoid.java
interface JavaIntefaceWithVoid {
    Void getVoid();
}

// FILE: KotlinOverridingJavaIntefaceWithVoid.kt
abstract class KotlinOverridingJavaIntefaceWithVoid: JavaIntefaceWithVoid {
    fun voidMethod() {}
}

Calling getJvmName on getVoid throws:

Cannot find descriptor for getVoid
java.lang.IllegalStateException: Cannot find descriptor for getVoid
	at com.google.devtools.ksp.processing.impl.ResolverImpl.getJvmName(ResolverImpl.kt:550)

Don't know why it is happening yet, investigating.

@yigit
Copy link
Collaborator Author

yigit commented Dec 21, 2020

oh, it is happening because of this check which tries to find it as a property even when it is not a property:
https://github.com/google/ksp/blob/master/compiler-plugin/src/main/kotlin/com/google/devtools/ksp/processing/impl/ResolverImpl.kt#L317

we can probably just make it fallback to the else to workaround it.

@yigit yigit changed the title getJvmName might throw when querying an interface method that returns void resolveJavaDeclaration fails if the java method starts with get or set Dec 21, 2020
yigit added a commit to yigit/ksp that referenced this issue Dec 21, 2020
This PR fixes a bug where KSP failed to resolve the java
declaration for a java method if its name starts with get
or set.

Fixes: google#200
Test: signatureMapper
ting-yuan pushed a commit that referenced this issue Dec 21, 2020
This PR fixes a bug where KSP failed to resolve the java
declaration for a java method if its name starts with get
or set.

Fixes: #200
Test: signatureMapper
copybara-service bot pushed a commit to androidx/androidx that referenced this issue Dec 22, 2020
This CL moves XType.is checks for known types to extension methods and
uses the TypeName (thats what JavacType did).

Initially, they were put into the interface because I wasn't sure how
well the typeName will work in KSP. At this point, it is one of the more
reliable parts of the KSP implementation (e.g. we do very well in
deciding whether we want it to be a primitive or not).

By moving them to extension methods, KSP and Javac implementations get
closer and becomes more consistent.

While creating a test case (KSP impl used to fail to detect boxed Void),
I hit a bug in KSP. Added a workaround for now.
google/ksp#200

Bug: 160322705
Test: XTypeTest & existing tests
Change-Id: I2ece2a9738faeef9a8530475f9f96330b35abaf3
neetopia pushed a commit that referenced this issue Dec 23, 2020
This PR fixes a bug where KSP failed to resolve the java
declaration for a java method if its name starts with get
or set.

Fixes: #200
Test: signatureMapper
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 a pull request may close this issue.

1 participant