Some testing of K2 in nontrivial android projects ...

# k2-adopters

[Zac Sweers]

Some testing of K2 in nontrivial android projects w/ Kotlin 1.9.0-Beta

• CatchUp - mostly works except for Dagger
• Circuit - mostly works except for Dagger and iOS
• Slack android repo
◦ dagger
◦ invisible member suppressions
◦ RxJava 3 calls
◦ Support for generating resources
Issues fell into one of the below categories. I've linked any existing or new bugs I've filed for them
• iOS support (kotlin native?) for K2: https://youtrack.jetbrains.com/issue/KT-59448
◦ It looks like, from here, kotlin native K2 support is not in 1.9.0-Beta and won't be until maybe 1.9.20.
• Dagger support (needs a kotlinx-metadata update): https://github.com/google/dagger/issues/3893
• Support for generating resources during compilations, which were de-scoped for K2.
◦ KSP supports K2 in spite of this though, so I'm not sure if this limitation is real? Would love clarification.
• Lack of support for suppressing invisible_member diagnostic: https://youtrack.jetbrains.com/issue/KT-59373
◦ We do rely on this in a few places in Slack due to lack of support for gradle test-fixtures in kotlin android projects 😕
• Some basic RxJava 3 calls crash the compiler: https://youtrack.jetbrains.com/issue/KT-59450
Another non-blocking issue I found and filed is this: https://youtrack.jetbrains.com/issue/KT-59449

Another annoying issue was that the compiler would write reports about log files, but these files never exist if I go to read them: https://youtrack.jetbrains.com/issue/KT-59451

[kirillrakhman]

Re INVISIBLE_MEMBER suppression, could you please check if changing the suppression to INVISIBLE_REFERENCE works? There is no INVISIBLE_MEMBER in K2.

[dmitriy.novozhilov]

@Zac Sweers thank you a lot, it's a great help for us

Support for generating resources during compilations, which were de-scoped for K2.

I doubt that issue you mentioned is related, because it is a feature request for compiler API from community. It doesn't relate to KSP

Lack of support for suppressing invisible_member diagnostic

As Kirill said, there is no INIVISIBLE_MEMBER anymore. You can add -Xrender-internal-diagnostic-names CLI arg to see names of each diagnostics reported during the build. It can help to adjust existing suppresses in case diagnostic name was changed (there is a number of such changes)
The issue you menitioned is not about supporting INIVISIBLE_MEMBER in K2, but about lack of any diagnostics in K2 in some cases where K1 reported INIVISIBLE_MEMBER

[Zac Sweers]

So the IDE isn't happy about it, but that does compile on the command line. As there's still no IDE support for K2, would that be expected to change in the update?

[Zac Sweers]

I doubt that issue you mentioned is related, because it is a feature request for compiler API from community. It doesn't relate to KSP

That's the one you linked me when I asked about this in the past 🙂 https://kotlinlang.slack.com/archives/C03PK0PE257/p1670251130734739?thread_ts=1670130290.585809&cid=C03PK0PE257

Basically I have a compiler plugin that generates resources during AnalysisHandlerExtension phase like KSP does. It tracks its own source dir and attaches it manually to the eventual resources task like KSP does, I guess what I'm wondering is if that means this is compatible with K2 and I misunderstood before (because KSP says this is ok too)

[kirillrakhman]

You can suppress both diagnostics to make the IDE happy.

[dmitriy.novozhilov]

So the IDE isn't happy about it, but that does compile on the command line

You can also enable internal mode in IDEA to see names of diagnostics for K1 in IDE too

Basically I have a compiler plugin that generates resources during AnalysisHandlerExtension phase like KSP does

Oh, I misunderstood your issue then. I thought you have some troubles with KSP, not the custom plugin
Could you please ask KSP team how did they done it (I'm not much into details) and check if their approach suties for you

[Zac Sweers]

Hey folks, my takeaway from the above was that the correct thing to use in K2 was INVISIBLE_REFERENCE, but that's now a warning to use in K2 and breaks -Werror. Is there something else we should be using?

[Zac Sweers]

It's also not possible to suppress that warning with another suppression (ERROR_SUPPRESSION appears to be non-suppressible)

[Zac Sweers]

Filed https://youtrack.jetbrains.com/issue/KT-67920

[dmitriy.novozhilov]

There is a flag -Xdont-warn-on-error-suppression, which should help you

[Zac Sweers]

That could help cover it but feels a little… heavy handed?

[kirillrakhman]

Have you considered making the internal API opt-in instead?

[Zac Sweers]

That carries ABI and Java exposure considerations, and ultimately is a stand-in for kotlin’s lack of package private. I see opt-in annotations as mostly useful for incubating experimental APIs, not internal access across grouped libraries

[dmitriy.novozhilov]

Our idea is to completely prohibit error suppression, as the behavior of the compiler is undefined if you are suppressing errors
But we understand, that right now there are some usecases, which cannot be covered in any way other then error suppresion (like the case with suppress of invisible reference), so for now it's allowed and there is a possibility to do it without warnings (only if you are really understand what you are doing)
So the plan is following:
• cover all known and reasonable cases of error suppression with language possibilities
• completely prohibit the error suppression

[dmitriy.novozhilov]

For the "internal between several modules" case we actually already have a language concept which covers it (friend modules), but it is not productized and there is no reasonable API to use it in the build systems (right now it works for the case "internal in main visible in `test`" case)

[Zac Sweers]

right, and my proposal is just to defer that prohibition until after friend modules is productionized. Otherwise those use cases are being prohibited without any viable alternative, which feels like the wrong order

[semoro]

So. The ERROR_SUPPRESSION is a warning and we aren’t yet planning to elevate it to an error. The intention here is to prevent error suppression from further spreading.
We will indeed consider the use-cases before completely prohibiting it.

And for the use-case - I completely understand it, but the problem is that we aren’t ready to guarantee (nor able to reasonable implement) anything about how the compiler behave in the case of error suppression. The goal here is to warn about entering the dangerous land.

[Zac Sweers]

warning without a replacement breaks the ability to use allWarningsAsError . I'd even settle for just a loud println, but we consider regressions to -Werror as build breaking since we rely on the ability to use that, and for things that trigger it to have viable alternatives/replacements

[semoro]

Well, you can still use the -Xdont-warn-on-error-suppression as it was mentioned before in the thread. It doesn’t break the ability to use allWarningsAsError

[Zac Sweers]

might as well rename it -Xsuppress-werror? 😅

[Zac Sweers]

my point is I don't think things should be deprecated if they have planned replacements that aren't available yet

[semoro]

I get it for sure. The problem is that - it isn’t deprecated because we are looking to replace it with something. But because it was never supposed to work in the first place and is broken.

[Zac Sweers]

isn't this supposed to be replaced with productionized friend paths/associated compilations?

[semoro]

This particular case is supposed to.
Yet, suppression of invisible reference is already broken and will be a problem already

[semoro]

-Xsuppress-werror - but it will have different meaning in such case, isn’t it?

[semoro]

What if error suppression wouldn’t be a warning from the standpoint of -Werror ?

[Zac Sweers]

fair enough!