GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:17:12Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/14391Make the simplifier independent of the typechecker2019-07-07T18:17:12ZJoachim Breitnermail@joachim-breitner.deMake the simplifier independent of the typecheckerI noticed that the simplifier module depends on all of the type checker, and HsSyn stuff, and renamer stuff, which I found strange.
After a little investigation, it seems that the simplifier depends on
CoreMonad, and that pulls some ver...I noticed that the simplifier module depends on all of the type checker, and HsSyn stuff, and renamer stuff, which I found strange.
After a little investigation, it seems that the simplifier depends on
CoreMonad, and that pulls some very few type-checker related things:
1. `
import TcRnMonad ( initTcForLookup )
import {-# SOURCE #-} TcSplice ( lookupThName_maybe )
`
for
`
thNameToGhcName :: TH.Name -> CoreM (Maybe Name)
thNameToGhcName th_name = do
hsc_env <- getHscEnv
liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name)
`
which is not even used in GHC, but only in GHC Plugins, so this could
probably be moved to a separate module pulled in by GhcPlugins.hs
1. `
import TcEnv ( lookupGlobal )
`
for
`
instance MonadThings CoreM where
lookupThing name = do { hsc_env <- getHscEnv
; liftIO $ lookupGlobal hsc_env name }
`
This might be a bit harder to disentangle. But if successful, it would
probably make building GHC in parallel quite a bit faster. And it just
seems strange to me that the Core-to-Core code should depend on the
type checker…
Simon says:
> Both of these code paths go through initTcForLookup which is massive overkill, as the comment with `TcEnv.lookupGlobal` says. There's clearly a ToDo here to strip off the redundant stuff and do a minimal lookup.
I am optimistically marking this as `newcomer` because it is a refactoring task, and a good way of learning a bit about various pieces, with a reasonably clear notion of “success”.
----
- \*UPDATE\*\* (April 2018, Phab:4503): both points described above are addressed to the extent when in order to close the ticket we need to do mere code movement. Namely.
1. `lookupThName_maybe` and `initTcForLookup` are eliminated from `CoreMonad.hs` completely. Its client, though, `thNameToGhcName`, is better to be moved in the future also, for it is not used in the `CoreMonad.hs` (or anywhere else) anyway. Joachim suggested “any module reexported by GhcPlugins (or maybe even that module itself)”.
1. `CoreMonad.hs` still calls `lookupGlobal` which is no longer bound to the typechecker monad, but still resides in `TcEnv.hs` — it should be moved out of Tc-land at some point in the future in order to close the ticket. 8.8.1Krzysztof GogolewskiKrzysztof Gogolewskihttps://gitlab.haskell.org/ghc/ghc/-/issues/15856GhostScript not available for hp2ps tests2019-07-07T18:02:42Zjrp2014GhostScript not available for hp2ps testsWhen I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`.
I don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer...When I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`.
I don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer libraries / headers that also need to be installed, but I don't recall seeing anything in the documentation about that).
The message "GhostScript not available for hp2ps tests" seems to come from a Python script that Simon Marlow produced in 2002. Unfortunately, there are two places where the message could have been generated.
There are probably 2 ways forward:
- a temporary bodge: taking the running of those tests that depend on hp2ps out of validation, in the same way that certain tests are not run when a dependent library is unavailable
- figuring out why the python script fails to understand that a ghostscript is actually present and fixing that
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GhostScript not available for hp2ps tests","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["ghostscript","gs","hp2ps","testsuite"],"differentials":[],"test_case":"","architecture":"","cc":["Simonmar"],"type":"Bug","description":"When I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`.\r\n\r\nI don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer libraries / headers that also need to be installed, but I don't recall seeing anything in the documentation about that).\r\n\r\nThe message \"GhostScript not available for hp2ps tests\" seems to come from a Python script that Simon Marlow produced in 2002. Unfortunately, there are two places where the message could have been generated.\r\n\r\nThere are probably 2 ways forward:\r\n\r\n - a temporary bodge: taking the running of those tests that depend on hp2ps out of validation, in the same way that certain tests are not run when a dependent library is unavailable\r\n\r\n- figuring out why the python script fails to understand that a ghostscript is actually present and fixing that","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Krzysztof GogolewskiKrzysztof Gogolewski