## Summary It appears that the breakpoint information isn't serialized into the interface files, so reloading a module into GHCi makes you no longer able to set breakpoints on it: * The first time around, it is compiled from scratch and the breakpoint locations are available * The second time, it is loaded from an iface which does not have breakpoint locations available This is relevant when options like -fwrite-if-simplified-core is being used to speed up the loading onto the interpreter/debugger. ~~I am not sure if this bug also reproduces with bytecode artifacts, or if bytecode artifacts have some way of persisting source-level breakpoint information~~ Turns out this does work for bytecode artifacts. It's important to make sure there is a regression test for this: https://gitlab.haskell.org/ghc/ghc/-/issues/27287#note_676258 ## Steps to reproduce ``` $ cat X.hs module X where myfun :: String -> String myfun xs = case reverse xs of [] -> "empty" xy -> xy $ ghci-9.14.1 -fwrite-if-simplified-core ghci> :load X.hs [1 of 1] Compiling X ( X.hs, interpreted )[interactive-session] Ok, one module loaded. ghci> :break myfun Breakpoint 0 activated at X.hs:(4,12)-(6,10) ghci> :load X.hs Ok, one module loaded. ghci> :break myfun Cannot set breakpoint on ‘myfun’: No breakpoint found for ‘myfun’ in module ‘X’ ghci> ``` ## Expected behavior The breakpoint on `myfun` should be set successfully after loading from an interface file. ## Environment * GHC version used: 9.14 Optional: * Operating System: * System Architecture: