Currently, GHC will produce errors and warnings with relative paths pointing to the input that caused it. This is less than ideal for any tooling consuming these diagnostics, because build tools will concurrently build many packages in different working directories and interleave the output from multiple GHC invocations. In particular, this makes using `next-error` in emacs a lot less useful than it could be with cabal-install's output. [Stack has some rather hackish code to post-process the diagnostics and to turn the relative paths absolute.](https://github.com/commercialhaskell/stack/blob/0740444175f41e6ea5ed236cd2c53681e4730003/src/Stack/Build/Execute.hs#L1896) I can personally report that this makes the development process a lot more pleasant! I think it'd be much cleaner to have a GHC flag for this at the source. `-fabsolute-diagnostic-paths` or something similar, subject to bikeshedding. I had a look at implementing this myself, and `mkLocMessageAnn` in `ErrUtils` would be the locus of the change. However, I can't figure out how that function should learn what the current working directory is! Any tips? Is that information lurking somewhere in `DynFlags`? <details><summary>Trac metadata</summary> | Trac field | Value | | ---------------------- | ------------ | | Version | 8.6.1 | | Type | Bug | | TypeOfFailure | OtherFailure | | Priority | normal | | Resolution | Unresolved | | Component | Compiler | | Test case | | | Differential revisions | | | BlockedBy | | | Related | | | Blocking | | | CC | | | Operating system | | | Architecture | | </details> <!-- {"blocked_by":[],"summary":"Flag for printing absolute paths in diagnostics","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently, GHC will produce errors and warnings with relative paths pointing to the input that caused it.\r\n\r\nThis is less than ideal for any tooling consuming these diagnostics, because build tools will concurrently build many packages in different working directories and interleave the output from multiple GHC invocations.\r\n\r\nIn particular, this makes using `next-error` in emacs a lot less useful than it could be with cabal-install's output.\r\n\r\n[https://github.com/commercialhaskell/stack/blob/0740444175f41e6ea5ed236cd2c53681e4730003/src/Stack/Build/Execute.hs#L1896 Stack has some rather hackish code to post-process the diagnostics and to turn the relative paths absolute.] I can personally report that this makes the development process a lot more pleasant!\r\n\r\nI think it'd be much cleaner to have a GHC flag for this at the source. `-fabsolute-diagnostic-paths` or something similar, subject to bikeshedding.\r\n\r\nI had a look at implementing this myself, and `mkLocMessageAnn` in `ErrUtils` would be the locus of the change. However, I can't figure out how that function should learn what the current working directory is! Any tips? Is that information lurking somewhere in `DynFlags`?","type_of_failure":"OtherFailure","blocking":[]} -->