KotlinCompilationWithResources

is deprecated in 1.8.20-Beta, but there is no replacement API for retrieving the

ProcessResources

task. Should I file a feature request, or is the expectation that this marker interface will go away but its current subtypes (

KotlinJvmCompilation

and

KotlinWithJavaCompilation

) will still expose

processResourcesTaskName

?

Hey I'm trying out context receivers. Works fine in my projects. I just started using them with annotations though. I see the KEEP says

As a matter of coding style, context receivers are defined after annotations and before other modifiers on a separate line.

https://github.com/Kotlin/KEEP/blob/master/proposals/context-receivers.md#detailed-design But when I try

class A

@Deprecated(message = "")
context(A)
fun Method() {}

It raises an error during compilation

Expecting a top level declaration

. I have to swap the order around and declare

context

first then the annotation. On Kotlin 1.8.0 Is it just me? should I raise this as a bug on Youtrack?

👋 Let's say I want to try to build against a recent RC (e.g. 1.8.20-RC-257 from yesterday), what's the way to do that? I think it involves adding Teamcity as a maven repository but not sure of what URL to use. Is there a doc for that? 🙏

@Sebastian Sellmair [JB] new

targetHierarchy

API is just super cool, thx! 🙂 But during my experiment here (https://github.com/whyoleg/ffi-kotlin/blob/52eb6a50d7b9e034fb8b09cc32e7e57a2e6ef68f/build-logic/src/main/kotlin/buildx-multiplatform.gradle.kts#L36) I found, that there is no

wasm

support there - is it possible to add it in 1.8.20, or only in 1.9.0?

Feel free to create a PR, I can try to cherry pick into 1.8.20, but 1.9.0 will certainly be OK for me

But I can also do it, just thought that contribution would be fun, given you can afford to spend that time and are interested

I'm having a weird issue where latest

-RC

(anything >=

1.8.20-RC-243

) show Java 19 warnings (and fail with

allWarningsAsErrors

). My JAVA_HOME is 19 but I'm supposed to compile with a 17 toolchain and target

1.8

(failed CI run). Does that ring a bell to anyone?

📣 Kotlin 1.8.20-RC is out with: ✅ New Kotlin K2 compiler updates ✅ AutoCloseable interface and Base64 encoding in stdlib ✅ New JVM incremental compilation enabled by default ✅ New Kotlin/Wasm compiler backend What’s new | Changelog Help us put the finishing touches 🪄 on the RC by reporting any lingering issues in YouTrack

Kotlin 1.8.20-RC2 has been released! 🎉

Why were these made

internal

in 1.9.0? Is there a different API that should be used for compiler plugins?

e: file:///Users/zacsweers/dev/slack/oss/circuit/build.gradle.kts:23:43: Cannot access 'NATIVE_COMPILER_PLUGIN_CLASSPATH_CONFIGURATION_NAME': it is internal in 'org.jetbrains.kotlin.gradle.plugin'
e: file:///Users/zacsweers/dev/slack/oss/circuit/build.gradle.kts:24:43: Cannot access 'PLUGIN_CLASSPATH_CONFIGURATION_NAME': it is internal in 'org.jetbrains.kotlin.gradle.plugin'
e: file:///Users/zacsweers/dev/slack/oss/circuit/build.gradle.kts:179:13: Cannot access 'PLUGIN_CLASSPATH_CONFIGURATION_NAME': it is internal in 'org.jetbrains.kotlin.gradle.plugin'
e: file:///Users/zacsweers/dev/slack/oss/circuit/build.gradle.kts:180:13: Cannot access 'NATIVE_COMPILER_PLUGIN_CLASSPATH_CONFIGURATION_NAME': it is internal in 'org.jetbrains.kotlin.gradle.plugin'

Seems 1.9.0-Beta introduces a bug with applying sourceset language settings to compiler options. 1.9-Beta vs 1.8.21.

Is there any reason for this inspection that was added to the 2023.2 Intellij EAP? It's a relatively common convention to use

PascalCase

for constants instead of

SCREAMING_CAMEL

Slack Conversation

Hello, after update to 1.9.0-Beta I've started to receive an error

Cannot invoke "kotlin.Lazy.getValue()" because "<local1>" is null

code:

@JsExport @OptIn(ExperimentalJsExport::class) public val constDataInMyApp: MyDataClass = MyDataClass(emptyArray())

data class AnotherDataClass(val name: String) {
 public val path: MyDataClass by lazy { constDataInMyApp.someFunc(this) }
}

It works well on 1.8.21

📣 The Kotlin 1.9.0-Beta release is out! Here are some highlights from this preview version: ✅ New Kotlin K2 compiler updates ✅ Stable ..< operator for open-ended ranges ✅ New path utility to create parent directories ✅ Preview of Gradle configuration cache in Kotlin Multiplatform ✅ Ability to configure standalone mode for iOS simulator tests in Kotlin/Native ✅ Changes for Android target support in Kotlin Multiplatform ➡️ Try it out! ⬅️

Some changes in Gradle that I want to bring attention to and ask to test so we could fix possible regressions before final release: • "org.jetbrains.kotlin.jvm" and "org.jetbrains.kotlin.android" plugins project level compiler options DSL (issue) • changes in Kapt tasks inputs configuration - default one should continue to work as before (issue) • further experimental optimization of new K/JVM IC -

kotlin.compiler.keepIncrementalCompilationCachesInMemory

(additionally to introduced in 1.8.20

kotlin.compiler.preciseCompilationResultsBackup

) (issue) • try K2 via

kotlin.experimental.tryK2

(issue)

With

kotlin.experimental.tryK2

the idea is that if I turn it on, then Kotlin will automatically figure out which compilation tasks can use K2 and which can't? So if some modules use Kapt then K2 will be skipped there (I think Kapt is still not supported in K2?), but for other modules K2 will be used?

Tried 1.9.0-Beta on a (complex) MPP + Compose project, previously at 1.8.10. Got stuck with what looks similar to https://youtrack.jetbrains.com/issue/KT-58777. Is there any known workaround at this time? Anything I could try to proceed?

🤖FYI: Google compose compiler compatible with 1.9.0-Beta is already published - https://androidx.dev/storage/compose-compiler/repository

I had to add a bunch of

public

modifiers to a module using

explicitApi()

after updating to 1.9 beta, The classes were public before but had no modifiers, which seems like a bug in previous versions? I've not used this mode before so I'm not sure, but the docs seem to indicate this should have been required before:

Visibility modifiers are required for declarations if the default visibility exposes them to the public API

Found a regression in 1.9.0-Beta around JSR305 wrt enums: https://youtrack.jetbrains.com/issue/KT-58917 false positive

Found another regression with serializer caching introduced in 1.8.20, and present in 1.9.0-Beta after the initial one (KT-58841) has been fixed: https://youtrack.jetbrains.com/issue/KT-58918

Is there more detail around the new

syncOptionsAsConvention

impl in KGP? We set some compiler options like

javaParameters

and disallow changes after we set them, but in 1.9.0-Beta we're surprised to see that KGP is setting these values again after we've set them (example in 🧵)

Idea plugin seems to be broken. Mainly it does not propagate gradle mudule dependencies to Idea project model.

I see a number of warnings in KMP about

android

being replaced by

androidTarget

, but strangely it seems Gradle kotlin DSL only sees Kotlin 1.8.21's plugin sources. At runtime it obviously appears to be 1.9.0-Beta, but I’m unable to compile against 1.9.0-Beta APIs because of the wrong indexing. Should I file this on youtrack or would this be a gradle issue? Repro - https://github.com/slackhq/circuit/pull/643

w: Please use `androidTarget` function instead of `android` to configure android target inside `kotlin { }` block.
See the details here: <https://kotl.in/android-target-dsl>

Some feedback for the new project extension APIs for compiler options: https://youtrack.jetbrains.com/issue/KT-58956

is there more detail on this feature mentioned in the 1.9.0-Beta release notes? https://youtrack.jetbrains.com/issue/KT-57930

👋 Hi. While trying to update the project NowInAndroid (with KSP

1.9.0-Beta-1.0.11

and Compose compiler

1.4.7-dev-k1.9.0-Beta-bb7dc8b44eb

), I had to manually register sourceSets for protobuf generated code otherwise Hilt would fail to compile the code because it could not find the generated classes on its classpath (logs). Could this be linked to KT-54468 ?

androidComponents.beforeVariants {
    android.sourceSets.register(it.name) {
        java.srcDir(buildDir.resolve("generated/source/proto/${it.name}/java"))
        kotlin.srcDir(buildDir.resolve("generated/source/proto/${it.name}/kotlin"))
    }
}

FYI:

kotlinx-metadata-jvm:0.6.1

is available on Maven Central: https://repo1.maven.org/maven2/org/jetbrains/kotlinx/kotlinx-metadata-jvm/0.6.1/

Kotlin/JS 1.9: it looks like

disableGranularWorkspaces

(introduced here) no longer exists? Looks like that's why I get asked to execute

kotlinUpgradeYarnLock

several times, depending on which module I've run my tests last.

Has someone tried to build kotlin-js project on 1.9? For me all

npm

dependencies are not resolved:

> Could not resolve all dependencies for configuration ':visionforge-threejs:npm'.
  The project declares repositories, effectively ignoring the repositories you have declared in the settings.
  You can figure out how project repositories are declared by configuring your build to fail on project repositories.
  See <https://docs.gradle.org/8.1.1/userguide/declaring_repositories.html#sub:fail_build_on_project_repositories> for details.
   > Could not find three:0.143.0:.
     Required by:
         project :visionforge-threejs
   > Could not find three-csg-ts:3.1.10:.
     Required by:
         project :visionforge-threejs
   > Could not find three.meshline:1.4.0:.
     Required by:
         project :visionforge-threejs