#15548: Make TABLES_NEXT_TO_CODE a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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: | -------------------------------------+------------------------------------- Description changed by nomeata: Old description:
The GHC API is used by programs that do not necessarily want to compile the same way as the normal GHC, so we want as much configuration in `DynFlags` and as little as possible hard-coded.
One such hard-coded flag is `TABLES_NEXT_TO_CODE`. It is currently used in these places:
* It is (of course) used a lot in rts. That’s fine. * It is used via tablesNextToCode :: DynFlags -> Bool in the Cmm code, so that code is already prepared to read the information from `DynFlags`. * There is `ghciTablesNextToCode :: Bool` in the GHCi code, some refactoring there might be needed to add a `DynFlag` there.
(The motivation is similar to #13477)
New description: The GHC API is used by programs that do not necessarily want to compile the same way as the normal GHC, so we want as much configuration in `DynFlags` and as little as possible hard-coded. One such hard-coded flag is `TABLES_NEXT_TO_CODE`. It is currently used in these places: * It is (of course) used a lot in rts. That’s fine. * It is used via `tablesNextToCode :: DynFlags -> Bool` in the Cmm code, so that code is already prepared to read the information from `DynFlags`. * There is `ghciTablesNextToCode :: Bool` in the GHCi code, some refactoring there might be needed to add a `DynFlag` there. (The motivation is similar to #13477) -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15548#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler