[BUG] using inout for decorator incorrectly causes weird compiler error

[Moosems]

Bug description

MRE:

# Correct implementation should be "fn decorator(borrowed func: fn() -> None) -> fn() escaping -> None:"
fn decorator(inout func: fn() -> None) -> fn() escaping -> None:
    fn inner1():
        func()
    return inner1

fn main():
    pass

Error:

mojo: /__w/modular/modular/KGEN/lib/MojoParser/ClosureEmitter.cpp:700: M::KGEN::LIT::StructDeclOp M::KGEN::LIT::ClosureEmitter::replaceNestedFunctionWithClosureImplStructDecl(llvm::SMLoc, M::KGEN::LIT::ASTDecl &, ArrayRef<M::KGEN::ParamDeclRefAttr>, M::KGEN::LIT::LITSignatureType): Assertion `isa<ParamDeclRefAttr>(captureType.getLifetime()) && "FIXME: Doesn't support complex lifetime captures yet"' failed.
Please submit a bug report to https://github.com/modularml/mojo/issues and include the crash backtrace along with all the relevant source codes.
Stack dump:
0.	Program arguments: mojo build -o /build/prog /source/prog.mojo
1.	Crash resolving decl body at loc("/source/prog.mojo":2:4)
    >> fn decorator(inout func: fn() -> None) -> fn() escaping -> None:
          ^............................................................
    >>     fn inner1():
    >>         func()
       ..............<
2.	Crash parsing statement at loc("/source/prog.mojo":3:5)
    >>     fn inner1():
           ^...........
    >>         func()
       ..............<
3.	Crash resolving decl signature at loc("/source/prog.mojo":3:8)
    >>     fn inner1():
              ^........
    >>         func()
       ..............<
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  mojo      0x0000560a824b4157
1  mojo      0x0000560a824b1d2e
2  mojo      0x0000560a824b47ef
3  libc.so.6 0x00007f46cb185520
4  libc.so.6 0x00007f46cb1d99fc pthread_kill + 300
5  libc.so.6 0x00007f46cb185476 raise + 22
6  libc.so.6 0x00007f46cb16b7f3 abort + 211
7  libc.so.6 0x00007f46cb16b71b
8  libc.so.6 0x00007f46cb17ce96
9  mojo      0x0000560a828e27b1
10 mojo      0x0000560a828f3224
11 mojo      0x0000560a828f148a
12 mojo      0x0000560a8290495e
13 mojo      0x0000560a8295fab2
14 mojo      0x0000560a8295cbc8
15 mojo      0x0000560a8295ca76
16 mojo      0x0000560a828f27b5
17 mojo      0x0000560a82904d24
18 mojo      0x0000560a82905438
19 mojo      0x0000560a82910032
20 mojo      0x0000560a829103bd
21 mojo      0x0000560a823cbd7c
22 mojo      0x0000560a823ce3a1
23 mojo      0x0000560a823c9756
24 mojo      0x0000560a823c7d5e
25 libc.so.6 0x00007f46cb16cd90
26 libc.so.6 0x00007f46cb16ce40 __libc_start_main + 128
27 mojo      0x0000560a823c76ae

Steps to reproduce

Run code here (Mojo Playground)

System information

N/A

[Moosems]

Out of curiosity while you're here, why is the escaping necessary? I couldn't find anything in the docs other than the changelogs here and those didn't help me out much. Also, the prints in the wrapper are never called... why?

fn hello_decorator(borrowed func: fn() -> None) -> fn() escaping -> None:
    fn inner1():
        print("Hello, this is before function execution")
        func()
        print("This is after function execution")
    return inner1

fn main():
    @hello_decorator
    fn function_to_be_used():
        print("This is inside the function !!")
    
    # calling the function
    function_to_be_used()

[jackos]

@arthurevans @scottamain fyi on comment just above, no docs currently on escaping

[jackos]

Minimal repro this also causes to parser crash:

fn decorator(inout func: fn() -> None):
    fn inner1():
        func()

fn main():
    pass

[arthurevans]

I've added an issue to document closures for 24.3. https://github.com/modularml/modular/issues/36537

Currently these keywords only appear when you're declaring a type that's a closure. There are two signatures, capturing for an @parameter closure (which unsafely captures variables in its closure) and escaping for a runtime closure, which can "escape" the function it's defined in (for example, inner1() here "escapes" from hello_decorator(). I think the Mojo team eventually wants to eliminate the need for these keywords but I cannot swear to that.

AFAIK, Mojo doesn't support dynamic decorators like you're trying to define. Mojo's current decorators are hardcoded.

(See https://docs.modular.com/mojo/roadmap#full-mlir-decorator-reflection)

To verify this you can add a print statement to the body of hello_decorator(), and you'll see that despite the parser not complaining about the @hello_decorator, it is in fact never called.

[Moosems]

Yes, I noticed the function ran but not the prints in the decorator (second comment)

[arthurevans]

@Moosems Right. I was just pointing out that's because the function hello_decorator never gets called. Support for python-style decorators isn't wired up in Mojo at this point.

[Moosems]

Are there any plans for that in the near/semi-near future?