Unable to generate IR for `string_functions.st`

[corbanvilla]

Describe the bug I'm attempting to generate the LLVM IR for the stdlib, but string_functions.st causes an issue. Specifically, it appears that lines 560-685 are causing the problem.

To Reproduce Steps to reproduce the behavior:

> cargo build
> ./target/debug/plc --ir ./libs/stdlib/iec61131-st/string_functions.st 

"/tmp/.tmp3DPFle/libs/stdlib/iec61131-st/string_functions.ll:304:9: error: stored value and pointer type do not match\n  store i8* %2, [81 x i8]*** %5, align 8\n        ^\n"

Expected behavior Generate valid IR and not error out. Once these lines are disabled, the IR for this file and all others generates without a problem.

I've attempted this on the latest build as well as the last few commits, but they all have been yielding this issue.

Any help is very much appreciated!

[ghaith]

@mhasel a good old friend returns.

@corbanvilla could yo try this on the 0.2 release please? It might be the parallel build that broke this.

[corbanvilla]

@ghaith Yes, it works fine for 0.2 release.

Also was able to get the backtrace for latest:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: GeneralError { message: "\"/tmp/.tmpRnZyHY/libs/stdlib/iec61131-st/string_functions.ll:304:9: error: stored value and pointer type do not match\\n  store i8* %2, [81 x i8]*** %5, align 8\\n        ^\\n\"", err_no: general__io_err }', compiler/plc_driver/./src/main.rs:7:32
stack backtrace:
   0: rust_begin_unwind
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:579:5
   1: core::panicking::panic_fmt
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panicking.rs:64:14
   2: core::result::unwrap_failed
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/result.rs:1750:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/result.rs:1090:23
   4: plc::main
             at ./compiler/plc_driver/./src/main.rs:7:5
   5: core::ops::function::FnOnce::call_once
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[mhasel]

I've had a look at this - seems like this has to do with the {ref} pragma in variadic functions. Happens also if you change the generic to INT. Compiles to IR without the pragma, panics with the pragma. Unfortunately, the fix isn't as simple as just removing the pragma from the declarations - that will result in an ugly SIGABORT due to misaligned memory when running the code

edit: The {ref} pragma wasn't an issue, since it works for string CONCAT functions without any problems. We were missing headers for the resolved generics (e.g. EQ__STRING) with the proper signatures. The above-linked PR should fix this.