[GHC] #14018: Expose more pipeline functionality to GHC API
#14018: Expose more pipeline functionality to GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There's many useful functionality in non-exposed modules. For example, `ghc/Main.hs` contains `doMake` [0], which is a one-shop stop for compiling all (non-Haskell + Haskell) source files. Now a GHC API client has to replicate much of this logic to get GHC-alike behavior. Similarly for `parseModeFlags`. Or is the intent here to encourage using of Frontend plugins instead of relying on these internals? [0]: http://stuff.codereview.me/#ghc/ghc/Main.hs?corpus=ghc-8.2.1-rc2&signature&line=696 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14018 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14018: Expose more pipeline functionality to GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by literon): Generally a lot of magic happening in directly in `main` and `main'`. I found #11194 which implies the Frontend Plugin mode is supposed to shortcut having to reimplement these. That said, the (agreeably short, relative to 'main') functionality of `doMake`, namely compiling the non-Haskell sources is not executed in frontend mode. I wonder if there is a resource (or if there should be) that describes caveats/differences of frontend mode vs other major modes? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14018#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14018: Describe Frontend Plugin vs othe major mode differences in manual. -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14018#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14018: Describe Frontend Plugin vs othe major mode differences in manual. -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by literon): For the record, I wrote up some warts of calling GHC API multiple times at https://gist.github.com/robinp/49c68c6f69f6aabfddee3cba42b4964f. The current state favors Frontend Plugin due to the global linker state, if robust compilation is needed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14018#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14018: Highlight differences of Frontend Plugin vs GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14018#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14018: Highlight differences of Frontend Plugin vs GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):
For the record, I wrote up some warts of calling GHC API multiple times
Thank you. Would you consider adding it to GHC's user-contributed documentation, here [https://wiki.haskell.org/GHC/As_a_library]? Better still, can we clean up those warts somehow? Eg shoudl the linker state be as global as it is? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14018#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14018: Highlight differences of Frontend Plugin vs GHC API -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by literon): Could do the writeup once the problem / solution crystallizes. It's not clear to me yet that (not) unloading non-Haskell objects is a fundamental limitation or just a missing feature. I was looking around, and for the uneducated sight the problem seems to be this: `preload_static` [1] in Linker.hs (called eventually by `loadCmdLineLibs`) calls either `dynLoadObjs` or `loadObj`, depending on `dynamicGHC`. But neither of those do any bookkeeping for `PersistentLinkerState`. It seems calling `dynLinkObjs` [2] (note `Link` not `Load` in name) would be more appropriate, since it updates the `objs_loaded` in `PLS`, so a later `unload` call could unload those as well. This sounds more in line with the Linker comment that `PLS` should be synced with the C linker state. However `dynLinkObjs`, while morally doing the same as `preload_static` + accounting, conditionally chooses `dynLoadObjs` or `loadObj` based on `dynamicInterpreter`. Latter seems to be defined the same as `dynamicGhc` except if an external interpreter is used, which I have no idea about. It would be insightful if someone knowledgeable about the linker code could comment if this has good reasons and a change is not feasible, or maybe is just historic leftover. [1]: http://stuff.codereview.me/#ghc/compiler/ghci/Linker.hs?corpus=ghc-8.2.1-rc2&signature&line=472 [2]: http://stuff.codereview.me/#ghc/compiler/ghci/Linker.hs?corpus=ghc-8.2.1-rc2&signature&line=854 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14018#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC