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

Missing @JvmSuppressWildcards annotation after KSType#replace() or KSType#asMemberOf() #1376

Closed
bcorso opened this issue May 4, 2023 · 1 comment · Fixed by #1425
Closed
Labels
bug Something isn't working P1 major features or blocking bugs
Milestone

Comments

@bcorso
Copy link

bcorso commented May 4, 2023

Say I have a property like the one below:

class MyClass<T> {
  var myList: @JvmSuppressWildcards List<Foo> = TODO()
}

If I resolve the property type, it has the @JvmSuppressWildcards annotation as expected. However, if I use KSType#replace() or KSPropertyDeclaration#asMemberOf() the resulting type does not have the @JvmSuppressWildcards annotation.

Example:

myList.type.resolve():
    toString(): [@kotlin.jvm.JvmSuppressWildcards] List<Any>
    getAnnotations(): [@JvmSuppressWildcards]

myList.asMemberOf(myStringClass):
    toString(): [@kotlin.jvm.JvmSuppressWildcards] List<Any>
    getAnnotations(): []

myList.type.resolve().let { it.replace(it.arguments) }:
    toString(): [@kotlin.jvm.JvmSuppressWildcards] List<Any>
    getAnnotations(): []

It's also interesting that in the later 2 cases the annotation still shows up in the KSType#toString() but just not in KSType#annotations. Poking around at the internals, I noticed that the annotations are still available in the type via KSTypeImpl.getKotlinType().getAnnotations().hasAnnotations(FQName), so one workaround at the moment is to use reflection to check for the annotation.

@bcorso
Copy link
Author

bcorso commented May 4, 2023

Note: This is similar to #1325 but not quite the same since this is happening for Koltin sources as well.

@neetopia neetopia added bug Something isn't working P1 major features or blocking bugs labels May 17, 2023
@neetopia neetopia added this to the 1.0.12 milestone May 17, 2023
copybara-service bot pushed a commit to androidx/androidx that referenced this issue Jul 6, 2023
This CL fixes a few issues:

    1. Adds logic to keep track of the synthetic `getFoo$annotations()`
       method using kotlin metadata, and automatically adds the
       annotations to the associated `JavacFieldElement`.
    2. `KspType` now keeps track of the "original annotations" of a type
       (or type argument) to work around the bug described in
       google/ksp#1376. That bug is technically
       fixed, but hasn't landed in an official release yet.
    3. Fixes the `acceptedTargets` for methods and constructors to include
       `AnnotationTarget.FUNCTION` and `AnnotationTarget.CONSTRUCTOR`
       respectively.
    4. Changes the `acceptedTargets` for fields to include both
       `AnnotationTarget.FIELD` and `AnnotationTarget.PROPERTY`. This seems
       to be more intuitive than only accepting `FIELD` since `XFieldElement`
       kind of represents both.
    5. Fixes type annotations on `KspTypeElement`'s super class and
       super interfaces in KSP

Test: XAnnotationTest.kt

Change-Id: I3c57e8169f30310f6d8dbdd5e7a741dfd9dc5e48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working P1 major features or blocking bugs
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants