"Function return type does not match operand type of return inst!"

[TurkeyMan]

I feel like I've seen this error several times before, although I haven't yet isolated the code in this case (because there's no reference to the source code, so I need to bisect).
Last time we saw something like this, it was a known issue in DMD that lead to this error, yet it still stands... is there a reason it wasn't fixed in DMD?

Function return type does not match operand type of return inst!
  ret ptr %3, !dbg !167190
 { i64, ptr }LLVM ERROR: Broken module found, compilation aborted!
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  ldc2            0x0000ab98b3cc725c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 64
1  ldc2            0x0000ab98b3cc51bc llvm::sys::RunSignalHandlers() + 56
2  ldc2            0x0000ab98b3cc795c
3  linux-vdso.so.1 0x0000ff91063b5820 __kernel_rt_sigreturn + 0
4  libc.so.6       0x0000ff9106117608
5  libc.so.6       0x0000ff91060ccb3c gsignal + 28
6  libc.so.6       0x0000ff91060b7e00 abort + 244
7  ldc2            0x0000ab98b3c335e4 llvm::report_fatal_error(llvm::Twine const&, bool) + 456
8  ldc2            0x0000ab98b3c3341c llvm::report_fatal_error(llvm::Twine const&, bool) + 0
9  ldc2            0x0000ab98b3acfc80 llvm::VerifierPass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) + 0
10 ldc2            0x0000ab98b3aa2148 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) + 420
11 ldc2            0x0000ab98b3fc9348 runOptimizationPasses(llvm::Module*, llvm::TargetMachine*) + 4968
12 ldc2            0x0000ab98b4055f40 writeModule(llvm::Module*, char const*) + 976
13 ldc2            0x0000ab98b4054db0 ldc::CodeGenerator::writeAndFreeLLModule(char const*) + 888
14 ldc2            0x0000ab98b0a3d6f4 codegenModules(Array<Module*>&) + 2256
15 ldc2            0x0000ab98b09bfa18 mars_tryMain(Param&, Array<char const*>&) + 1652
16 ldc2            0x0000ab98b0a3f9e4 cppmain() + 8236
17 ldc2            0x0000ab98b42040e4 _D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZv + 84
18 ldc2            0x0000ab98b4203e30 _d_run_main2 + 492
19 ldc2            0x0000ab98b4203c28 _d_run_main + 144
20 ldc2            0x0000ab98b4052240 main + 744
21 libc.so.6       0x0000ff91060b84c4
22 libc.so.6       0x0000ff91060b8598 __libc_start_main + 152
23 ldc2            0x0000ab98b0a43570 _start + 48
Aborted (core dumped)
make: *** [Makefile:194: bin/arm64_unittest/openwatt_test] Error 134
Error: Process completed with exit code 2.
****

[thewilsonator]

I remember this occurring if you have two different files that have the same extern(C) function prototype that takes (or I guess returns) a struct that each of the files defines.

[kinke]

so I need to bisect

If the !167190 is stable, you could dump the IR via -output-ll -disable-verify, and grep for the return instruction, to get at the problematic function, which seems to return a pointer instead of an expected slice.

[dnadlinger]

I feel like I've seen this error several times before, although I haven't yet isolated the code in this case (because there's no reference to the source code, so I need to bisect).

Sounds like this ought to be a prime candidate for DustMite/…?

I've wondered a few times (also working on another LLVM-based compiler) whether it would be worth it to povide better location information even for internal compiler errors such as this that ought not to happen. I haven't quite gotten around to checking whether the LLVM verified would give us enough information for that, though.