Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr`
An HsExpr
should look exactly as a user wrote some Haskell code. Its pretty printer should therefore be quite dumb. Just print out the code! But a few places in GHC create HsExpr
s and aren't scrupulous with regard to adding HsPar
nodes where source syntax would need them. Thus, well-meaning souls have added pprParendExpr
calls to the HsExpr
pretty-printer to try to cover these cases.
Simon and I think that we should remove all recursive uses of pprParendExpr
from the HsExpr
pretty-printer and instead add the HsPar
s where necessary.
It was recently reported that the following test cases break when simply removing pprParendExpr
:
Unexpected failures:
deriving/should_fail T4846 [stderr mismatch] (normal)
generics GenDerivOutput [stderr mismatch] (normal)
generics GenDerivOutput1_0 [stderr mismatch] (normal)
generics GenDerivOutput1_1 [stderr mismatch] (normal)
ghci/scripts T10248 [bad stderr] (ghci)
indexed-types/should_compile PushedInAsGivens [stderr mismatch] (normal)
safeHaskell/safeLanguage SafeLang10 [stderr mismatch] (normal)
safeHaskell/safeLanguage SafeLang17 [stderr mismatch] (normal)
typecheck/should_fail T8603 [stderr mismatch] (normal)
typecheck/should_fail tcfail177 [stderr mismatch] (normal)
See also considerable commentary on D1114.
Trac metadata
Trac field | Value |
---|---|
Version | 7.10.2 |
Type | Task |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |