Unexpected behavior for higher-order code generation

[NeuralCoder3]

Unexpected results are produced when the generation of LLVM Code from Thorin code containing higher-order code
is attempted.

Small example:

extern "C" {
    fn g(fn(i32)->i32) -> i32;
    fn h(i32) -> i32;
}

fn main() -> i32 {
    g(h)
}

generates the llvm code

declare i8* @malloc(i64)

declare i32 @g({i32} (i32) // Error
declare i32 @h(i32)


define i32 @main() {
main_1038:
    %g_cont_1071.ret = call i32 @g({i32} (i32 @h) // Error
    br label %return_1066
    
return_1066:
    %_1077 = phi i32 [ %g_cont_1071.ret, %main_1038 ]
    ret i32 %_1077
    
}

Steps: impala -emit-llvm -Othorin [file.impala]

The behavior occurs also at similar points where function types are used.
For instance at the allocation of a pointer slot for a function.

Observed behavior: Invalid LLVM Code is produced.
Expected behavior: The code generation should probably throw an error if unhandled higher-order code is encountered at this point.

[leissa]

The LLVM code generator cannot cope with higher order functions. Right now, there are two things in the work to cope with this:

1. The cleanup branch has a new phase in the work which specializes higher-order functions.
2. The closeure-conv branch has work on the way to closure-convert such things.

Still, the LLVM code generator should probably just throw an exception with a reasonable error message, if sth unexpected occurs.