Comments (9)
Seems like it has nothing to do w/ Any or equals.
If the overriding method has protected
, it fails.
e.g. with the following code:
val source1 = SourceFile.java("TestClass.java", """
public class TestClass extends Base {
protected void test() {}
}
""".trimIndent())
val base = SourceFile.java("Base.java", """
public class BaseClass {
protected void test() {}
}
""".trimIndent())
Checking TestClass.test
overrides BaseClass.test
also throws.
If I change the protected
in TestClass
to public
, it works fine.
from ksp.
some more information.
Seems like it is an issue specific to KSFunctionDeclarationDescriptorImpl
while it works fine with KSFunctionDeclarationJavaImpl
.
More specifically, if I get a class via resolver.getClassDeclarationByName
, it returns KSClassDeclarationDescriptorImpl
whereas if i get it via a kotlin subclass (symbol.superTypes.first().resolve()?.declaration
), then it returns KSClassDeclarationJavaImpl
and it works properly.
So seems like an issue in resolver.
I think the fix is straightforward to extend the check to handle protected
but i'm not sure if that'll just hide another bug.
Why does the resolver return two different implementations based on the call site?
from ksp.
I tried extending the javaModifiers
test and the value returned from java are a bit different:
C: PUBLIC ABSTRACT
staticStr: PRIVATE
s1: FINAL JAVA_TRANSIENT
i1: PROTECTED JAVA_STATIC JAVA_VOLATILE
intFun: JAVA_SYNCHRONIZED JAVA_DEFAULT
foo: ABSTRACT JAVA_STRICT
abstractVoidMethod: PROTECTED
If I visit the declaration by directly getting it via:
resolver.getClassDeclarationByName(
resolver.getKSNameFromString("C")
)
it prints:
C: ABSTRACT PUBLIC
abstractVoidMethod: OPEN PROTECTED
hashCode: OPEN PUBLIC OVERRIDE
equals: OPEN PUBLIC OPERATOR OVERRIDE
toString: OPEN PUBLIC OVERRIDE
intFun: OPEN
foo: ABSTRACT
staticStr: FINAL PRIVATE
s1: FINAL
i1: FINAL PROTECTED JAVA_STATIC
In some ways, getting it via resolver seems to be returning a more complete information (e.g. OPEN
modifier is added).
from ksp.
some more information.
Seems like it is an issue specific to
KSFunctionDeclarationDescriptorImpl
while it works fine withKSFunctionDeclarationJavaImpl
.More specifically, if I get a class via
resolver.getClassDeclarationByName
, it returnsKSClassDeclarationDescriptorImpl
whereas if i get it via a kotlin subclass (symbol.superTypes.first().resolve()?.declaration
), then it returnsKSClassDeclarationJavaImpl
and it works properly.So seems like an issue in resolver.
I think the fix is straightforward to extend the check to handleprotected
but i'm not sure if that'll just hide another bug.
Why does the resolver return two different implementations based on the call site?
They should always be same implementation, I noticed this issue last week but since the fix was rather small and inside the implementation detail therefore I didn't make it an issue, was planning to address it myself, sorry for the confusion.
from ksp.
I tried extending the
javaModifiers
test and the value returned from java are a bit different:C: PUBLIC ABSTRACT staticStr: PRIVATE s1: FINAL JAVA_TRANSIENT i1: PROTECTED JAVA_STATIC JAVA_VOLATILE intFun: JAVA_SYNCHRONIZED JAVA_DEFAULT foo: ABSTRACT JAVA_STRICT abstractVoidMethod: PROTECTED
If I visit the declaration by directly getting it via:
resolver.getClassDeclarationByName( resolver.getKSNameFromString("C") )
it prints:
C: ABSTRACT PUBLIC abstractVoidMethod: OPEN PROTECTED hashCode: OPEN PUBLIC OVERRIDE equals: OPEN PUBLIC OPERATOR OVERRIDE toString: OPEN PUBLIC OVERRIDE intFun: OPEN foo: ABSTRACT staticStr: FINAL PRIVATE s1: FINAL i1: FINAL PROTECTED JAVA_STATIC
In some ways, getting it via resolver seems to be returning a more complete information (e.g.
OPEN
modifier is added).
It's true that descriptors contains most detailed information as they are fully resolved, but they are not representing the original code structure, like the implicit OPEN for Java symbols, and hence it will be nice if users won't rely on this buggy behavior of getClassDeclarationByName always returns descriptor based implementation.
from ksp.
i think both are probably fine from developer's perspective as long as it is consistent. but when they are inconsistent, it will be really hard to workaround as most of the code in the symbol processor does not necessarily know how the KSClassDeclaration was acquired.
from ksp.
i think both are probably fine from developer's perspective as long as it is consistent. but when they are inconsistent, it will be really hard to workaround as most of the code in the symbol processor does not necessarily know how the KSClassDeclaration was acquired.
If consistent mean .isOpen() will return always return true for an open class regardless of JavaImpl or DescriptorImpl, they are consistent by our design. We are making modifiers only include explicit modifier just to make sure there is a way to still inspect code. Developers should look at utility functions like isOpen rather than relying on modifiers which can differ by platform.
from ksp.
I agree with that.
actually i was leaning for the same thing as i'm prototyping the abstraction for room.
I found some places where we unnecessarily access elements APIs. Trying to guard them beyond an abstraction to avoid modelling too much of the elements API.
from ksp.
android/kotlin#51 includes a fix to this reproduce project.
from ksp.
Related Issues (20)
- A failure occurred while executing com.google.devtools.ksp.gradle.KspAAWorkerAction HOT 8
- `KSP2` version `2.0.0-1.0.23` crashes on Moshi codegen with `NoSuchElementException: Collection contains no element matching the predicate.`
- Increase your Kotlin version and remove root level plugin and add this
- How to use KSP Processor provider on custom android library? HOT 2
- 2.0.20-Beta2 - [ksp] java.lang.NullPointerException
- Dagger hilt options were not recognized by ksp
- Accessing resources by name HOT 2
- IncompatibleClassChangeError with Kotlin 2.0.20-Beta2 HOT 1
- Dispatchers.IO Not Supported for File Creation
- generated kotlin code does not handle null properly when java generated code does HOT 1
- KSP2: Exception when using Moshi KSP and @ JsonQualifier HOT 1
- Better documentation of compatibility matching of ksp and gradle
- why this version not found in gradle? HOT 3
- [KSP2] getSymbolsWithAnnotation() doesn't work if the annotation is an alias in KOTLIN_LIB
- Room Entity with class function throws [ksp] [MissingType]
- incremental: aggregating outputs should always be invalidated
- Configuration with name 'kspJvm' not found. HOT 2
- Goog ksp 4 me
- Incremental compilation / processing issue HOT 1
- [KSP2] Qualified names of nested annotations from JAVA_LIB is null
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ksp.