A modern programming language that makes developers happier.

kotlinlang

I'm working on a bug fix in Metro (<https://github.com/ZacSweers/metro/pull/343/files>) where everything works as expected when there's a single compilation, but am running into some interesting annotation argument behavior when I test the same setup using two modules/compilations.

I have this object definition
```@ContributesBinding(AppScope::class, binding = binding&lt;ContributedInterface&gt;())
          object Impl1 : ContributedInterface, OtherInterface```
where I want to evaluate the `binding` argument of `ContributesBinding` inside a `FirSupertypeGenerationExtension`. When the above snippet is defined with the rest of my code in a single module, the `binding` arg is accessible as a `FirFunctionCall` which allows me to get its parameterized type `ContributedInterface`. Once I move the `Impl1` snippet to a separate module and compilation, the `FirSupertypeGenerationExtension` sees the `binding` arg as a `FirAnnotationImpl` rather than some type of call. This results in the binding arg coming back as null since we're not able to access the parameterized type.

Any ideas on additional changes I might need to make to support both use-cases and access the argument as a call-type? Also happy to provide more details if needed

A `FirAnnotationImpl` has `typeArguments: List&lt;FirTypeProjection&gt;` just like a `FirFunctionCall` does, they just don't share a super class/interface. Should be able to handle both cases if all you need to do is extract the type arguments.

I suspect the different is because in one case it is being parsed from source and in the other it is being read from serialized metadata. We might just have a slight inconsistency.

Screenshot 2025-04-21 at 6.56.49 PM.png

In this case the type arguments show up as null/empty unfortunately :sweat_smile:

Whelp, doesn't look like we actually save the type arguments to metadata :grimacing: mind opening a bug?

Done! <https://youtrack.jetbrains.com/issue/KT-76954/Some-type-arguments-are-not-saved-to-metadata-in-FIR>