GHC panic depending on what a Haskell module is named

I'm trying to make bindings for the imgui C++ library and have encountered an apparent bug. I'm unable to produce a minimal example so I've packed up the whole project in a zip file. It only works on Windows for now but I assume this problem is platform dependant anyways.

There's a module UI.Imgui that imports two things. A FunPtr wrapping function and an actual function defined in a .cpp file. Another module Main imports this module.

If the project is run in a repl (in my case I'm doing stack repl) and then the test function is evaluated it results in a GHC panic

ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.10.3 for x86_64-unknown-mingw32):
        loadObj "C:\\Users\\Luka\\AppData\\Local\\Temp\\ghc5900_0\\ghc_5.o": failed

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Now here's the fun part. If you rename the module, file and it's import to something like Imgui2 it works. If you rename it to UI2.Imgui (with appropriate folder renaming) it also works!

I'm sure a huge portion of the code is irrelevant. I couldn't reproduce this with simple .cpp files.

Here's a link to the file (3MB) https://dl.dropboxusercontent.com/u/35032740/ShareX/2016/05/imgui.zip

Update: Ok so it seems that the "reason" why renaming the file works is because I forgot to change the entry in the cabal file so the next time I run the repl it fails to recompile the project but it launches the repl using the previous build. Why it doesn't panic in that case I have no idea.

Also, here's another thing that fixes is: Run the repl -> try test -> GHC panic -> save the Imgui file (without changing anything, just so you can :r it) -> do :r in GHCi -> try test -> works

changed weight to 5

added GHCi Tbug Trac import labels

changed the description

changed the description

Could you try to reduce your testcase a bit? Ideally you'd slim it down to a simple .cpp file, without any external libraries.

Also please provide detailed instructions for how to reproduce the problem. Assume only tools and libraries mentioned on Building/Preparation/Windows are installed. Thanks.

At the very least, a version that uses cabal instead of Stack would be useful. As the extra level of abstraction makes it harder to debug GHC failures :)

I will try to shrink the problem a bit if I can, but I feel like this might be pretty pointless since the bug might not exist with GHC 8.0

It's a bit impractical for me to test if the same thing happens on the newer version at the moment, though maybe if I get a better example someone else can try it.

added runtime crash label

added Windows info needed labels

added Pnormal label