not sure if this is the right channel or not-> but I am seeking help with my dependencies, which is a huge mess. Why I came about this: chatgpt claims that my usage of ksp and versions could cause issues with my assisted factories for hilt that cause me to get no such method found, it recommended i start using kapt but doing this causes a bunch of cascading issues- What i am seeking : • are there any good tutorials on how to properly understand and manage dependencies on android, its always been an area that I just keep smashing it until it works and then hope for the best, but Id like to gain deeper understanding/mastery of those dependencies and understanding better pluggins and apply false and other such parameters. • possibly if someone wants to volunteer for a video call I can share screen and walk you through the mess, though I know this is a big ask/not likely, so mostly the point above is my goal today.

👋 Hi everyone, Is there a way to generate a

.kt

file using Kotlin Poet during the FIR stage - for example, inside a FirFunctionCallChecker- and include it in the build source sets?

Hi has anyone, dealt with IR lowering issues that started after updating to Kotlin version 2.2?

Are there any plans to release a 2.2.0 build of

org.jetbrains.kotlin:kotlin-annotation-processing-compiler

?

What to do if I got

The root cause java.lang.RuntimeException was thrown at: org.jetbrains.kotlin.backend.jvm.codegen.FunctionCodegen.generate(FunctionCodegen.kt:48)
	at org.jetbrains.kotlin.backend.common.CodegenUtil.reportBackendException(CodegenUtil.kt:107)
	at org.jetbrains.kotlin.backend.common.CodegenUtil.reportBackendException$default(CodegenUtil.kt:90)
	at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invokeSequential(performByIrFile.kt:54)
	at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invoke(performByIrFile.kt:41)
	at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invoke(performByIrFile.kt:27)
	at org.jetbrains.kotlin.config.phaser.CompilerPhaseKt.invokeToplevel(CompilerPhase.kt:62)
	at org.jetbrains.kotlin.backend.jvm.JvmIrCodegenFactory.invokeCodegen(JvmIrCodegenFactory.kt:371)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.runCodegen$cli(KotlinToJVMBytecodeCompiler.kt:413)

With kotlin serialisation?

In the FIR extensions doc, it mentions:

There are plans to implement some more extensions which allow to

• declare new kinds of contracts

Any info about what that means exactly? Does that mean adding syntax to the

contract

block, and providing a way to store that in the binary?

Any good examples of

FirTypeAttributeExtension

? I'm trying to implement Scala's Capture Checking as a FIR plugin.

FirTypeAttributeExtension

doesn't seem enough on its own though, and likely I have to add some checkers as well, no? Does

FirTypeAttributeExtension

affect call resolution as well? I don't actually want that, so I'm hoping it doesn't.

Is there a way, in a compiler plugin, to somehow get called when the overall compilation is finished with a failed/success state? I'm outputting some auxiliary files and would like to be able to build up their models in memory and write them at the end rather than appending as we go

So, here's my take on the current experimental state of Context Parameters! I love them. But I got some annoyances to talk about. When converting all my Context Receivers to Context Parameters, 90% of all the time, I had to use

_:

because my "top level" functions do not directly care about the parameter name, they do not call anything from those context values. All they do is call lower-level functions, usually bridge functions I'd say, that specifically need the parameter and give it an explicit name. Now, seeing that my most used character in modern Kotlin will be the

_

, I wonder whether from a language design perspective it would be more beneficial to allow all context parameters where the name is irrelevant to be simply stated just like context receivers where before: without any name spec in front of the type. Just like even now a type alias works. Type aliases, interestingly did not change at all coming from context receivers! I think it might be done like this because right now coming from context receivers it is not a good idea to allow the same syntax to mean different things, but on the long run: would it not be possible to omit this unnecessary, cumbersome piece of

_:

everywhere?

Speaking of Context parameters (and arrow), i ran into a bit of a weird unexpected interaction between lambdas with receivers and lambdas with context parameters when nested with each other i brought up in the arrow channel. Basically when i call a function that takes a lambda with a

Raise<E>

receiver, then within that lambda i call a function that takes a

context(Raise<E>) ()->T

, calling

raise(...)

within the inner lambda block has ambiguity on whether it should refer to

Raise<E>.raise()

on the outer receiver or

context(_: Raise<E>) raise()

on the inner context and the compiler seems to always choose the outer receiver over the inner context. I would expect it to work like having nested lambda with receiver blocks where it makes the call on the nearest/innermost matching receiver and just include available context params in that search

Hey folks, just wanted to check that https://youtrack.jetbrains.com/issue/KT-53477 was still on the radar somewhere - is there any chance of it getting addressed sometime soon? It's particularly painful when developing compiler plugins as getting Gradle to use the shadow jar for a project or included build dependency is not trivial (especially since you don't control the actual dependency addition). In the meantime, is there any harm in setting all the native compiler plugin configurations to be transitive myself?

I'm trying to implement a compiler plugin to convert code from

@Repr
value class DateT {

}

to

@JvmInline
value class DateT(val repr: REPR) {

}

I've successfully implement the add @JvmInline annotation, and adding a value parameter in constructor, but I'm having trouble declaring the val repr. Should I do it in fir generation? or fir transform? I got VALUE_CLASS_CONSTRUCTOR_NOT_FINAL_READ_ONLY_PARAMETER, did I miss something, how do I properly create a property in Fir so it is a correct inline value class?

i'm working on updating a compiler plugin to use kotlin 2.2 and i'm getting the following error:

Exception during IR lowering

with a stacktrace that starts out

[ERROR] The root cause java.lang.IndexOutOfBoundsException was thrown at: java.base/java.util.AbstractList.subListRangeCheck(AbstractList.java:509)
[ERROR] 	at org.jetbrains.kotlin.backend.common.BackendException$Companion.report(BackendException.kt:31)
[ERROR] 	at org.jetbrains.kotlin.backend.common.BackendException$Companion.report$default(BackendException.kt:15)
[ERROR] 	at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invoke(PerformByIrFilePhase.kt:37)
[ERROR] 	at org.jetbrains.kotlin.backend.common.phaser.PerformByIrFilePhase.invoke(PerformByIrFilePhase.kt:15)
[ERROR] 	at org.jetbrains.kotlin.backend.common.phaser.PhaseEngine.runPhase(PhaseEngine.kt:64)
[ERROR] 	at org.jetbrains.kotlin.backend.common.phaser.PhaseEngine.runPhase$default(PhaseEngine.kt:56)
[ERROR] 	at org.jetbrains.kotlin.backend.jvm.JvmIrCodegenFactory.invokeLowerings(JvmIrCodegenFactory.kt:359)
[ERROR] 	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.runLowerings$cli(KotlinToJVMBytecodeCompiler.kt:415)
[ERROR] 	at org.jetbrains.kotlin.cli.pipeline.jvm.JvmBackendPipelinePhase.executePhase(JvmBackendPipelinePhase.kt:85)
...
[ERROR] Caused by: java.lang.IndexOutOfBoundsException: toIndex = 1
[ERROR] 	at java.base/java.util.AbstractList.subListRangeCheck(AbstractList.java:509)
[ERROR] 	at java.base/java.util.ArrayList.subList(ArrayList.java:1190)
[ERROR] 	at org.jetbrains.kotlin.backend.jvm.lower.SuspendLambdaLowering.generateContinuationClassForLambda(SuspendLambdaLowering.kt:162)
[ERROR] 	at org.jetbrains.kotlin.backend.jvm.lower.SuspendLambdaLowering.generateAnonymousObjectForLambda(SuspendLambdaLowering.kt:133)
[ERROR] 	at org.jetbrains.kotlin.backend.jvm.lower.SuspendLambdaLowering.access$generateAnonymousObjectForLambda(SuspendLambdaLowering.kt:113)
[ERROR] 	at org.jetbrains.kotlin.backend.jvm.lower.SuspendLambdaLowering$lower$1.visitBlock(SuspendLambdaLowering.kt:123)

i'm sure the problem is in my plugin, but the error doesn't give me any information about what code actually caused the problem. any suggestions on chasing down where the actual problem is?

debugging things suggests that the issue is a suspend lambda generated by my plugin. are there any examples of how to correctly generate a suspend lambda for a launch block?

I have ir

FILE: LibC.kt
    public final typealias pid_t = R|kotlin/Long|
    public abstract interface LibC : R|kotlin/Any| {
        public abstract fun getpid(): R|{pid_t=} kotlin/Long|

        public final companion object Companion : R|kotlin/Any| {
            public final fun create(): R|kotlin/Unit|

            private constructor(): R|LibC.Companion| {
                super<R|kotlin/Any|>()
            }

        }

       public final companion object Companion : R|kotlin/Any| {
            public final val getpid: R|java/lang/foreign/MemorySegment|
                public get(): R|java/lang/foreign/MemorySegment|

            public final class Companion : R|kotlin/Any| {
                public final val getpid: R|java/lang/foreign/FunctionDescriptor|
                    public get(): R|java/lang/foreign/FunctionDescriptor|

            }

        }
    }

But when I tried to use statement

LibC.Proc.getpid

it errors

NO_COMPANION_OBJECT

what caused this error? (Proc is generated) It seems like

FirStandaloneQualifierChecker

runs before nested

FirDeclarationGenerationExtension

, how could I fix it?

The

ownerGenerator

is internal so I can not modify if I use buildRegularClassCopy to insert the companion object

I saw 2 issues on youtrack related to my issue https://youtrack.jetbrains.com/issue/KT-68020/K2-run-FirSupertypeGenerationExtension-over-generated-declarations and https://youtrack.jetbrains.com/issue/KT-68133/Properly-implement-lazy-resolve-for-generated-classes-with-additionally-generated-supertypes

is there something special that needs to be done for intellij to correctly load and execute compiler plugins in a maven project? if i run straight from the ide it doesn't work - throws 500s with a stacktrace of

! java.lang.NullPointerException: null
! at kotlin.coroutines.jvm.internal.ContinuationImpl.getContext(ContinuationImpl.kt:105)
! at kotlin.coroutines.jvm.internal.ContinuationImpl.intercepted(ContinuationImpl.kt:112)
! at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsJvmKt.intercepted(IntrinsicsJvm.kt:182)
! at kotlinx.coroutines.DelayKt.delay(Delay.kt:172)

but if i run

mvn compile

first, it works fine.

Wrong channel, move to #C19FD9681 https://kotlinlang.slack.com/archives/C19FD9681/p1752067077072709 Hi together, at my company, when we enable the gradle configuration cache (default enabled in gradle 9), we get an error from the Kotlin Compiler.

Execution failed for task ':compileKotlin'.
> Error while evaluating property 'disableMultiModuleIC' of task ':compileKotlin'.
   > Invocation of 'Task.project' by task ':compileKotlin' at execution time is unsupported with the configuration cache.

We traced it back to this line in the Kotlin compiler: https://github.com/JetBrains/kotlin/blob/master/libraries/tools/kotlin-gradle-plug[…]ommon/kotlin/org/jetbrains/kotlin/gradle/tasks/KotlinCompile.kt It only happens on jenkins, locally all is fine. It is reproducible and happens in a cleaned workspace (also in a dirty one). We are unsure why the error only happens on jenkins. Maybe a timing issue with the lazy? Any idea what that could be?

Hey Koders ✌️ I'm currently working on a fork of the Kotlin compiler that supports running Kotlin/Native on an ESP32. You can check out my work so far here: https://github.com/BierDav/kotlin-konan But most problems I'm currently facing have a lot to do with my Windows for ARM development environment 🙃 Until now I always could easily add the

arm64

versions of the binaries such as Node, WASM, and so on. But now I'm a bit stuck with the usage of

kotlin-native-prebuilt

which currently doesn't have

arm64

versions for neither Linux or Windows Sooooo I was just wondering if someone of you could just add those two build targets to the build pipeline? I suppose this is not that big of a Hussle, because now we even have

arm64

windows Docker images. I would be really grateful for that 🙂 (I know, I can just build it myself and I will probably do that know, but in long term it would really make my life a whole lot easier and eventually)

I am attempting to use FIR generate a nested class for each constructor an annotated class has. I'm attempting to use a FIR scope to get the constructor declarations in

getNestedClassifiersNames

, and running into problems because

FirClassDeclaredMemberScopeImpl

attempts to list the nested classifiers on creation, resulting a stack overflow. This is used by

FirClassSymbol.constructors

and

FirSession.declaredMemberScope

. Presumably this is to allow inclusion of static/companion object members, which I don't care about here. I've found several options to work around it: 1. Look at the declarations in

classSymbol.fir.declarations

or

classSymbol.declarationSymbols

directly - this has all sorts of warning annotations and seems like a bad idea 2. Use

session.declaredMemberScopeWithLazyNestedScope(classSymbol.fir, emptyList())

- this uses the FIR scopes, but requires manually accessing

.fir

. Doesn't seem to result in the generated name showing up unless it's also in the

existingNames

argument, which defeats the point. What's the best option here? Is there an option I'm missing?

👋 Hi everyone! I implemented a basic Kotlin compiler plugin using K2 that checks class instantiations and prints a warning on the build output log if a class of type

com.names.inspector.Dog

is defined with a name ending in a specific suffix. The attached images illustrate its behavior. The plugin works correctly on JVM but fails with iOS targets. When running the task

compileKotlinIosArm64

, it fails with an error

java.lang.NoClassDefFoundError: com/names/inspector/Dog

indicating that a class defined in a

commonMain

sourceSet is not recognized properly, even though it is exported correctly for each iOS target. Could you please help me understand why this plugin fails for iOS targets?

Not to complain - but this really goes fast - 2.2 just release a month ago and 2.2.20 beta already pops up. I can not keep up 🙂

Not sure if it is useful to post here, but I think I found a bug: https://youtrack.jetbrains.com/issue/KT-79078/Unexpected-NoWhenBranchMatchedException-when-using-sealed-class

I'm trying to generate a method in FIR that has a default parameter value using

createMemberFunction

. The javadocs of

valueParameter

say that if

hasDefaultValue

is true the value must be generated in IR. That's fine. But when I set it, I don't even get that far -

Fir2IrVisitor

throws because the expression for the default value is

STUB

. Is there a way around this? I can build the default value in FIR but it's rather awkward and IIUC we shouldn't be building bodies in FIR in plugins

At the IR level, are there any rules or assumptions made about the ordering of statements in constructor bodies? In particular, I'd like to have the primary constructor set a field before calling the super constructor or instance initializer, but am worried that there's some level of platform incompatibility I'll run into.

How can i get the type of a property that does not have its type explicitly specified? ie

val property = "value"

Current code:

val environment = KotlinCoreEnvironment.createForProduction(
        projectDisposable = Disposer.newDisposable(),
        configuration = CompilerConfiguration(),
        configFiles = EnvironmentConfigFiles.JS_CONFIG_FILES
    )

    val fileWithProperty = PsiManager.getInstance(environment.project)
        .findFile(LightVirtualFile("FileWithProperty.kt", INSTANCE, "val property = \"value\"")) as KtFile

    val myVal = fileWithProperty.declarations.first() as KtProperty

when i inspect

myVal

there is nothing that hints towards the type (string) of the property. Reading this channel I think I need a binding context, but I don't understand how to create one. For context, I am building a CLI app (not a plugin)

When updating from 2.2.0 to 2.2.20-Beta1 IrTypeSystemContext::commonSuperType(List<IrType>) become unresolved reference. What is the alternative?

Explicit API mode - I was surprised that I need to mark interface methods with explicit visibility also