Feat: use GHC native error reporting

guibou commented 2 years ago

Instead of manually generating the error message with line / caret / ... and passing this string to TH fail, we use GHC native error reporting functionality.

The benefits are:

Less code (all the manual formatting code is removed)
More in sync with other errors
KILLER FEATURE: the error location is now correctly reported by external tools, such as haskell-language-server. No more error spanning over your complete template haskell splice, the correct error will be pinpointed accurately.

This was achieved using an unsafeCoerce, to access the complete GHC api. I've found about this hack when reading GHC source code and later found that it was described in

https://www.tweag.io/blog/2021-01-07-haskell-dark-arts-part-i/

Profpatsch commented 2 years ago

Since this is a hack (that might break in future GHC versions), can we somehow ask upstream to expose the necessary functions?

guibou commented 2 years ago

@Profpatsch for sure, the ticket is here: https://gitlab.haskell.org/ghc/ghc/-/issues/10330

Actually, I was trying to address this ticket when I realized that this hack could be used.

guibou commented 2 years ago

AFAIK that's a 10 minute GHC hack, we just need a new function in the Quasi interface, and write the different implementation. This can even be done in a backward compatible way so the new function just provides an irrelevant location if not propertly written.

Profpatsch commented 2 years ago

Hm, I’m trying out the new version, but I can’t get it to only report the subset (e.g. here I typoed “hostname”):

Maybe I need a newer version of hls? I’m pretty sure I’m using the patched version of PyF.

> haskell-language-server --version
haskell-language-server version: 1.7.0.0 (GHC: 9.0.2)

guibou / PyF

Feat: use GHC native error reporting #101