A modern programming language that makes developers happier.

kotlinlang

How do I return an integer constant created via `<http://IrConstImpl.int|IrConstImpl.int>` from a `Function0&lt;Int&gt;` lambda/local function that i've created?

I was doing
```body = DeclarationIrBuilder(pluginContext, symbol).irExprBody(replacement)```
where `replacement` is the `IrConst`, but that breaks the JVM verifier and LLVM

I was hoping to find something where I didn't really have to know that boxing was required

Maybe try a regular irBlockBody with one statement being an irReturn(myConstant)
If that doesn't work, I would try storing the IrConst in an irTemporary and then return that irTemporary

yeah i started with the block body and thought i was cool moving to an expression. temporary is a good idea. will try!

Expression probably doesn't even change much in the output binary, but I do agree it really feels more "right" to use an expression body there. I suspect that maybe even expression bodies might still need an irReturn for some reason, although I'm not sure (easy way to check would be to compile an expression body and look at its IR). I haven't worked with IR in a while though so maybe I'm missing something more subtle.

I'd expect irReturn(irConst) to work here
What kind of verification error did you get?

The stack has an int and it wants an Object (Integer)

I can get the actual message here in a bit

```java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
    com/example/cite/LambdasKt$propertyReferenceLine$1.invoke()Ljava/lang/Integer; @2: checkcast
  Reason:
    Type integer (current frame, stack[0]) is not assignable to 'java/lang/Object'
  Current Frame:
    bci: @2
    flags: { }
    locals: { 'com/example/cite/LambdasKt$propertyReferenceLine$1' }
    stack: { integer }
  Bytecode:
    0000000: 100e c000 13b0 ```

Huh, that's weird, in my practice it was lowered after
You might want to dump something like `val a = { 0 }` and check what it gets compiled to on IR level

I was propagating the wrong type in the wrong place and it was preventing the autoboxing

Not surprised, IR is very particular about it sometimes
Glad that helped!

But also weirdly flexible? I was specifying a completely nonsensical type before and it worked for String constants, just not int.

Yeah, the validation doesn't check it at all most of the times, it just depends if downstream lowering uses this type or not