How do you hide a generated FIR function from the ...

# compiler

[Caleb B]

How do you hide a generated FIR function from the user? I need it to exist in FIR for resolution, but it shouldn't be invokable, and I definitely don't want it to show up like this:

[Youssef Shoaib [MOD]]

Not sure if you can hide it from the inlay hint.
For resolution, maybe you can have it be deprecated level error or hidden, but that might mess up resolution.
You could instead add your own checker that complains if someone calls the method directly.

[Caleb B]

Deprecated(HIDDEN) does mess up resolution, sadly.

There's no harm in someone calling it, but it's just clutter in the IDE.

[Zac Sweers]

Deprecated(HIDDEN) does mess up resolution, sadly.

I (and kotlinx-serialization) use this heavily with no issues, what specific issue are you seeing?

[Caleb B]

I was getting an "unknown reference" error when I last tried it. I'll try it again?

[Zac Sweers]

That's pretty vague :). It should work fine, it's just an annotation

[Caleb B]

I mean my generated function (MyClass#set-someProperty(Int)) wasn't able to be resolved in the FIR when I generated the @Deprecated(HIDDEN) annotation on it. Something like R|<local>/x|MyClass.<Unresolved reference:set-someProperty>#|(Int(2))

[Caleb B]

I'll try again though

[Caleb B]

Yeah, same error in FIR:

R|<local>/x|.R|foo/MyClass.set-someProperty<Inapplicable(INAPPLICABLE): foo/MyClass.set-someProperty>#|(String(a string))

with the generated function in question being:

@R|kotlin/Deprecated|(message = String(Use the native property setter), level = kotlin/DeprecationLevel.HIDDEN) public final fun set-someProperty(<set-?>: R|kotlin/String|): R|kotlin/Unit| {
            this@R|foo/MyClass|.R|foo/MyClass.someProperty| = R|<local>/<set-?>|
        }

[Zac Sweers]

Still pretty vague as you're not giving any sort of context how you're encountering it. The annotation looks off though, like you're not passing a message parameter

[Caleb B]

I'm forced to remap all assignments of an annotated property blindly to a set-propertyName function, since I can't get the type of the rvalue when the assignment transformer is run

[Zac Sweers]

Sorry, hard to help if you don't give more context. I'd recommend looking at what kotlinx-serialization or metro’s compiler plugins do for examples

[Caleb B]

The full context is that this:

class MyClass {
    @HasCustomSetters
    var someProperty: String = ""
}

fun test() {
    val inst = MyClass()
    inst.someProperty = "some string"
}

is being transformed into this:

class MyClass {
    @HasCustomSetters
    var someProperty: String = ""

    fun `set-someProperty`(`<set-?>`: String) {
        this.someProperty = `<set-?>`
}
}

fun test() {
    val inst = MyClass()
    inst.`set-someProperty`("some string")
}

This is my basic "are the transformers being run" diagnostic test; no errors are supposed to be thrown here.

[Zac Sweers]

The problem is in your compiler code, which that is not :)

[Caleb B]

Okay! I'm happy to provide that, all you needed to do was ask

[Caleb B]

\:)

[Caleb B]

gdi

[Caleb B]

slack is the worst place to send code, so I'm trying to not flood the chat with it 😕

[Caleb B]

Here's the declaration generation: https://paste.ofcode.org/thAWfwjmhFD5jeVyACKh3m

[Caleb B]

The deprecated annotation starts at line 39

[Zac Sweers]

Slack is fine for short snippets, it shouldn't require explicit asks in a thread about “what’s wrong with my code” for you to share what you've tried

[Zac Sweers]

I think the examples I mentioned above would be a good exercise to learn more about this pattern

[Caleb B]

I mean you just asked for the context, no need to get hostile

[Caleb B]

I figured you wanted the context for the problem, not the attempts

[Caleb B]

mb

[Caleb B]

Basically, the error only occurs when that buildAnnotation block (starting at line 39) is present. Without it, no error.

[Caleb B]

I'm really grateful for your willingness to help, btw. I'd given up on the annotation for a while

[Caleb B]

Everything about the method works, I've tested it thoroughly, it's just that the @Deprecated annotation... if I had to guess, it causes the diagnostic test to completely ignore the function? Or it's just reporting the "calling a deprecated function" diagnostic?

Whether it can't resolve the function at all, or it just gives a "deprecated" error when you do the assignment, either way it's pretty bad for the user. So I gave up on it, and was hoping someone knew an alternative for hiding it from intellisense.

[Caleb B]

Is there anything else you want to see to help understand what's up? I'm fine with sending more code, I just hate it when I try to help someone and they send me a github link and say "help plz"

[Caleb B]

In all honesty, I'm considering running a final transformer on every function body to remap any set-bar(PropertysOwnType) calls back to the vanilla property sets. This could all be avoided if I just had access to the rvalue's type in the assignment expression...

[Caleb B]

Wait, there is a bit more.
Here's the full diagnostic test kt: https://paste.ofcode.org/7Jkxx4wBYwzHstKHZ45pYG
Full FIR dump: https://paste.ofcode.org/Bgy4GgSWnDTNXsyBHucZWQ
and the actual exception being thrown:

java.lang.IllegalStateException: ARGUMENT_TYPE_MISMATCH: Argument type mismatch: actual type is 'String', but 'Int' was expected. at bar.kt:(181,191)

I'm very grateful for the help

[Youssef Shoaib [MOD]]

I think there's a key difference between what Metro and Kotlinx Serialization do, vs what your plugin does. You're using an assign alterer extension, which runs resolution on your transformed (unresolved) FIR, while the 2 aforementioned plugins generate resolved FIR. Unresolved FIR, I conjecture, works the same as the user typing in code, as in, HIDDEN will hide the declaration from resolution completely; when resolution runs on your unresolved FIR, it won't see any HIIDEN declarations.

[Caleb B]

That would make sense. I went ahead and tried adding the deprecated annotation in a status transformer, but sadly that makes the annotation not show up in the IDE, so that's a bust too.

[Youssef Shoaib [MOD]]

There's some magic that hides suspendCoroutineUninterceptedOrReturn and startCoroutineUninterceptedOrReturn from IDE. Maybe see if that's configurable somehow?

[Caleb B]

Ooh... I'll definitely check that out, thank you!

[Youssef Shoaib [MOD]]

I got curious...
So seemingly the function isExcludedFromAutoImport is what excludes these things, at least it shows up in completion-related code.
It doesn't have any Kotlin customization (instead, there's a hard list of packages), but it does use JavaProjectCodeInsightSettings, whatever that is.