- ghc-devs - Haskell.org

Howto build optimized with stack traces/9.2.3 build broken?
by Benjamin Maurer 03 Jul '22

03 Jul '22

Hey all, I'm trying to debug a segfault caused by my optimization. GHC only segfaults when compiled with -O2 and my flag, i.e., I used the "perf" flavour: > ./hadrian/build -j "stage1.*.ghc.hs.opts += -fregs-ssa" --flavour=perf However, I can't get a stack trace. [1] suggests I need a profiling build for that. So I tried: > ./hadrian/build -j "stage1.*.ghc.hs.opts += -fregs-ssa" --flavour=perf+debug_info+profiled_ghc+no_dynamic_ghc Unfortunately, I'm using GHC 9.2.1 from ghcup to bootstrap and this version doesn't come with profiling enabled base [2]. 8.10.7, which I have installed, can't compile ghc anymore (it seems). So I tried 9.2.3 from ghcup and that gives me the strangest errors. Basically, the compiler seems completely bricked. I installed 9.2.3, ran "hadrian/build clean", "./configure && ./boot" and the same line as above with both "default" and "perf" flavours. When I try to compile nofib/spectral/simple, I get: > /home/ben/Projekte/haskell/ghc/_build/stage1/bin/ghc -O2 Main.hs > [1 of 2] Compiling Main ( Main.hs, Main.o ) > Main.hs:1125:1: error: lexical error (UTF-8 decoding error) (Main.hs only has 1124 lines though, file was not modified, compiles fine with any other ghc version) But most programs I tried give me: > /home/ben/Projekte/haskell/ghc/_build/stage1/bin/ghc -O2 Main.hs > ghc: Unable to commit 283468890112 bytes of memory > ghc: Exiting. The system might be out of memory. Oh kay. I got 16GB RAM, 10 gig available. GHC 9.2.3 works fine. Is my flavour combination bad, or what is broken here? Any other (better) way to get an optimized build with all the debugging aids I can get? I heard GHC 9.2.2 is a broken release, or does anyone know whether it works on Linux x86_64 (and comes with profiling libs from ghcup) - maybe I can get a working version using that? I'd try, but creating a new build takes almost an hour and I have spent most of the day trying to solve this. I am puzzled and desearate to fix my bug and get a working compiler. Appreciate any help! Best Regards, Benjamin [1] https://gitlab.haskell.org/ghc/ghc/-/blob/master/hadrian/doc/debugging.md [2] https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/296

1 0

RST Documentation Trick for reference links
by Matthew Pickering 01 Jul '22

01 Jul '22

Hello, I noticed myself writing things like: ``` and enable the eventlog using :rts-flag:`-l ⟨flags⟩`. ``` When in fact what I wanted was to create a link the eventlog options but render the link as just -l rather than -l <flags>.. but I thought I had to write the whole thing to get the linter to not complain. It turns out can achieve this goal using the following syntax: ``` and enable the eventlog using :rts-flag:`-l <-l ⟨flags⟩>`. ``` ie, include the thing you actually want to reference in angular brackets < > and the text you want to render before that. Yet another thing which has changed my life for good. Cheers, Matt

1 0

Guide for testing hackage documentation upload
by Matthew Pickering 01 Jul '22

01 Jul '22

Hi all, In case anyone needs this in the future or is interested then I wrote a little guide about how to test the upload of hackage documentation locally. https://gitlab.haskell.org/ghc/ghc/-/wikis/testing-hackage-documentation Cheers, Matt

1 0

Imminent Removal of Make Build System
by Matthew Pickering 30 Jun '22

30 Jun '22

Hi all, We are imminently going to remove the make build system. See: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7094 There is quite extensive documentation about using hadrian, the best place to start is the in-tree documentation: https://gitlab.haskell.org/ghc/ghc/-/blob/master/hadrian/README.md For packagers: * The 9.4.* series will be the last release series which can be built with the make build system. * 9.6.* will only be able to be built using hadrian. * See ghcs-nix for an example of how to modify your own build system to use hadrian: https://gitlab.haskell.org/bgamari/ghcs-nix/-/blob/master/hadrian.nix * Sam Derbyshire is creating a guide aimed at packagers describing how to migrate their build plans. Cheers, Matt

2 1

Re: Migration guide for multiple home units
by Erdi, Gergo 30 Jun '22

30 Jun '22

PUBLIC Thanks, based on this I got things going. I might have to come back to you if it turns out something's still broken in my original full application. -----Original Message----- From: Matthew Pickering <matthewtpickering(a)gmail.com> Sent: Tuesday, June 21, 2022 12:54 AM To: Erdi, Gergo <Gergo.Erdi(a)sc.com> Cc: ÉRDI Gergo <gergo(a)erdi.hu>; GHC Devs <ghc-devs(a)haskell.org>; Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com> Subject: [External] Re: Migration guide for multiple home units My issue was caused by running the program in a dirty tree :) Find the modified program here - https://clicktime.symantec.com/39Wzk4MM32vW4JJm9h9nYC96xn?u=https%3A%2F%2Fg… I compiled it with HEAD. Hope you can make sense of it, I think it's simpler than before. Cheers, Matt On Mon, Jun 20, 2022 at 5:47 PM Matthew Pickering <matthewtpickering(a)gmail.com> wrote: > > Gergo, I rewrote your example program for the new API but didn't quite > manage to finish today. I will finish it off and post it tomorrow. > > Matt > > On Mon, Jun 20, 2022 at 6:16 AM Erdi, Gergo <Gergo.Erdi(a)sc.com> wrote: > > > > PUBLIC > > > > I managed to get this working, but I would like some feedback from Matt or others on whether this is the intended way of doing this. > > > > 1. The `extendMG` change can be brute-forced just to keep things going, by looking up dependency `ModSummary`s by `ModName` (we don't have full `Module`s at this point yet!): > > > > registerModSummary :: (GhcMonad m) => ModSummary -> m () registerModSummary ms = modifySession \env -> > > let mg = hsc_mod_graph env > > -- TODO: of course with a bit more housekeeping we can do better than this... > > edges = [ NodeKey_Module $ msKey ms' | dep <- deps, ms' <- mgModSummaries mg, ms_mod_name ms' == dep ] > > mg' = extendMG mg edges ms > > in env{ hsc_mod_graph = mg' } > > where > > deps = map (unLoc . snd) $ ms_textual_imps ms > > > > 2. `registerModule` can be kept mostly as-is, since it only uses `modifyUnitState` to change the active unit: > > > > registerModule :: (GhcMonad m) => ModDetails -> ModIface -> m () registerModule details iface = modifySession $ extendHpt . addModule > > where > > hmi = HomeModInfo iface details Nothing > > > > mod = mi_module iface > > modOrig = ModOrigin (Just True) [] [] True > > > > addModule = modifyUnitState $ \us -> us > > { moduleNameProvidersMap = M.insert (moduleName mod) (M.singleton mod modOrig) $ moduleNameProvidersMap us > > } > > > > extendHpt = hscUpdateHUG $ addHomeModInfoToHug hmi > > > > modifyUnitState :: (UnitState -> UnitState) -> HscEnv -> HscEnv modifyUnitState f env = env > > { hsc_unit_env = let ue = hsc_unit_env env in > > let units = ue_units ue > > units' = f units > > in ue_setUnits units' ue > > } > > > > 3. The tricky part is getting `addUnit` right. For this, based on the implementation of `initUnits`, I came up with the following: > > > > modifyUnitEnv :: (UnitEnv -> UnitEnv) -> HscEnv -> HscEnv modifyUnitEnv f env = env > > { hsc_unit_env = let ue = hsc_unit_env env in f ue > > } > > > > addUnit :: DynFlags -> UnitId -> HscEnv -> HscEnv addUnit dflags unitId = modifyUnitEnv $ \ue -> > > let dbs = ue_unit_dbs ue > > unit_state = ue_units ue > > home_unit = ue_homeUnit ue > > in flip updateHug ue $ unitEnv_insert unitId $ HomeUnitEnv > > { homeUnitEnv_units = unit_state > > , homeUnitEnv_unit_dbs = dbs > > , homeUnitEnv_dflags = dflags > > , homeUnitEnv_hpt = emptyHomePackageTable > > , homeUnitEnv_home_unit = home_unit > > } > > > > setCurrentUnit :: UnitId -> HscEnv -> HscEnv setCurrentUnit unitId = > > modifyUnitEnv $ ue_setActiveUnit unitId > > > > > > So my questions about this: > > > > 1. How does setting the home unit make sense? By doing this, I am effectively setting the home unit to `main` for all units, since that's the initial `ue_homeUnit` of the initial unit environment. Or does it not matter because after `addUnit`, I call `setCurrentUnit` anyway? I've found that I can't use the unit I am just adding as its own home unit, because that then leads to module name resolution problems in `main`: every imported module from `main` is searched for in `main` instead of its correct unit. > > > > 2. Speaking of `main`, why is it that when adding units, I have to skip `mainUnitId`, otherwise module resolution breaks again? > > > > 3. Unlike the previous version, I am no longer creating and putting `UnitInfo`s anywhere. Where is this going to bite me? Where (if anywhere) should I put `UnitInfo`s with the new setup? > > > > Thanks, > > Gergo > > > > > > -----Original Message----- > > From: ÉRDI Gergő <gergo(a)erdi.hu> > > Sent: Sunday, June 19, 2022 12:32 PM > > To: Erdi, Gergo <Gergo.Erdi(a)sc.com> > > Cc: GHC Devs <ghc-devs(a)haskell.org>; Montelatici, Raphael Laurent > > <Raphael.Montelatici(a)sc.com> > > Subject: [External] Re: Migration guide for multiple home units > > > > > > On Thu, 16 Jun 2022, Erdi, Gergo via ghc-devs wrote: > > > > > Is there a migration guide for GHC API clients for the new “multiple home units” > > > feature? > > > > OK so in concrete terms, please see my attached program which is a heavily cut-down, standalone version of my real program. On commit fd42ab5fa1df847a6b595dfe4b63d9c7eecbf400^ (i.e. > > 3219610e3ba6cb6a5cd1f4e32e2b4befea5bd384) it compiles and works as expected. On commit fd42ab5fa1df847a6b595dfe4b63d9c7eecbf400 onwards, two problems pop up: > > > > 1. `extendMG` has changed and now requires manually specifying outgoing dependency edges. I thought the whole point of `summariseFile` was to collect this information? The reason I need to `extendMG` at that point is to get intra-unit orphan instances working. > > > > 2. `modifyUnitState` and its two uses (`addUnit` and `registerModule`) need to be updated to the new API. I think it makes sense that these need changing, since they touch exactly on the issue of which units are being compiled right now. However, I don't know how to update these. Also, I guess `setHomeUnit` should change the `CurrentUnit` instead of the `HomeUnit` now? > > > > Thanks, > > Gergo > > > > This email and any attachments are confidential and may also be > > privileged. If you are not the intended recipient, please delete all > > copies and notify the sender immediately. You may wish to refer to > > the incorporation details of Standard Chartered PLC, Standard > > Chartered Bank and their subsidiaries at https: > > //www.sc.com/en/our-locations > > > > Where you have a Financial Markets relationship with Standard > > Chartered PLC, Standard Chartered Bank and their subsidiaries (the > > "Group"), information on the regulatory standards we adhere to and > > how it may affect you can be found in our Regulatory Compliance > > Statement at https: //www.sc.com/rcs/ and Regulatory Compliance > > Disclosures at http: //www.sc.com/rcs/fm > > > > Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. > > > > Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. > > > > Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. > > > > Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

1 1

Release Plans - 9.4.1 and 9.2.4
by Matthew Pickering 30 Jun '22

30 Jun '22

Hello all, Welcome to another update on our release plans. 9.4.1 (Ben Gamari) ~~~~ We proceed smoothly onwards towards the release at the end of July. The alpha3 was released last week - https://discourse.haskell.org/t/ghc-9-4-1-alpha3-now-available/4701 The next release is scheduled to be the first release candidate. 9.2.4 (Zubin Duggal) ~~~~ We intend to also publish a new version in the 9.2 series before the end of July. The priority of this release is motivated by: * Adding support for the DeepSubsumption language extension * Fixing some critical RTS bugs Cheers, Matt

1 0

GHC 9.4.1-alpha3 now available
by Ben Gamari 24 Jun '22

24 Jun '22

The GHC developers are happy to announce the availability of the third alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.4.1-alpha3). This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by our Hadrian build system, it's possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1-alpha3/docs/users_guide/9.4.1-note…

1 0

Re: Migration guide for multiple home units
by Erdi, Gergo 20 Jun '22

20 Jun '22

PUBLIC I managed to get this working, but I would like some feedback from Matt or others on whether this is the intended way of doing this. 1. The `extendMG` change can be brute-forced just to keep things going, by looking up dependency `ModSummary`s by `ModName` (we don't have full `Module`s at this point yet!): registerModSummary :: (GhcMonad m) => ModSummary -> m () registerModSummary ms = modifySession \env -> let mg = hsc_mod_graph env -- TODO: of course with a bit more housekeeping we can do better than this... edges = [ NodeKey_Module $ msKey ms' | dep <- deps, ms' <- mgModSummaries mg, ms_mod_name ms' == dep ] mg' = extendMG mg edges ms in env{ hsc_mod_graph = mg' } where deps = map (unLoc . snd) $ ms_textual_imps ms 2. `registerModule` can be kept mostly as-is, since it only uses `modifyUnitState` to change the active unit: registerModule :: (GhcMonad m) => ModDetails -> ModIface -> m () registerModule details iface = modifySession $ extendHpt . addModule where hmi = HomeModInfo iface details Nothing mod = mi_module iface modOrig = ModOrigin (Just True) [] [] True addModule = modifyUnitState $ \us -> us { moduleNameProvidersMap = M.insert (moduleName mod) (M.singleton mod modOrig) $ moduleNameProvidersMap us } extendHpt = hscUpdateHUG $ addHomeModInfoToHug hmi modifyUnitState :: (UnitState -> UnitState) -> HscEnv -> HscEnv modifyUnitState f env = env { hsc_unit_env = let ue = hsc_unit_env env in let units = ue_units ue units' = f units in ue_setUnits units' ue } 3. The tricky part is getting `addUnit` right. For this, based on the implementation of `initUnits`, I came up with the following: modifyUnitEnv :: (UnitEnv -> UnitEnv) -> HscEnv -> HscEnv modifyUnitEnv f env = env { hsc_unit_env = let ue = hsc_unit_env env in f ue } addUnit :: DynFlags -> UnitId -> HscEnv -> HscEnv addUnit dflags unitId = modifyUnitEnv $ \ue -> let dbs = ue_unit_dbs ue unit_state = ue_units ue home_unit = ue_homeUnit ue in flip updateHug ue $ unitEnv_insert unitId $ HomeUnitEnv { homeUnitEnv_units = unit_state , homeUnitEnv_unit_dbs = dbs , homeUnitEnv_dflags = dflags , homeUnitEnv_hpt = emptyHomePackageTable , homeUnitEnv_home_unit = home_unit } setCurrentUnit :: UnitId -> HscEnv -> HscEnv setCurrentUnit unitId = modifyUnitEnv $ ue_setActiveUnit unitId So my questions about this: 1. How does setting the home unit make sense? By doing this, I am effectively setting the home unit to `main` for all units, since that's the initial `ue_homeUnit` of the initial unit environment. Or does it not matter because after `addUnit`, I call `setCurrentUnit` anyway? I've found that I can't use the unit I am just adding as its own home unit, because that then leads to module name resolution problems in `main`: every imported module from `main` is searched for in `main` instead of its correct unit. 2. Speaking of `main`, why is it that when adding units, I have to skip `mainUnitId`, otherwise module resolution breaks again? 3. Unlike the previous version, I am no longer creating and putting `UnitInfo`s anywhere. Where is this going to bite me? Where (if anywhere) should I put `UnitInfo`s with the new setup? Thanks, Gergo -----Original Message----- From: ÉRDI Gergő <gergo(a)erdi.hu> Sent: Sunday, June 19, 2022 12:32 PM To: Erdi, Gergo <Gergo.Erdi(a)sc.com> Cc: GHC Devs <ghc-devs(a)haskell.org>; Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com> Subject: [External] Re: Migration guide for multiple home units On Thu, 16 Jun 2022, Erdi, Gergo via ghc-devs wrote: > Is there a migration guide for GHC API clients for the new “multiple home units” > feature? OK so in concrete terms, please see my attached program which is a heavily cut-down, standalone version of my real program. On commit fd42ab5fa1df847a6b595dfe4b63d9c7eecbf400^ (i.e. 3219610e3ba6cb6a5cd1f4e32e2b4befea5bd384) it compiles and works as expected. On commit fd42ab5fa1df847a6b595dfe4b63d9c7eecbf400 onwards, two problems pop up: 1. `extendMG` has changed and now requires manually specifying outgoing dependency edges. I thought the whole point of `summariseFile` was to collect this information? The reason I need to `extendMG` at that point is to get intra-unit orphan instances working. 2. `modifyUnitState` and its two uses (`addUnit` and `registerModule`) need to be updated to the new API. I think it makes sense that these need changing, since they touch exactly on the issue of which units are being compiled right now. However, I don't know how to update these. Also, I guess `setHomeUnit` should change the `CurrentUnit` instead of the `HomeUnit` now? Thanks, Gergo This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

2 2

Migration guide for multiple home units
by Erdi, Gergo 19 Jun '22

19 Jun '22

PUBLIC Hi, Is there a migration guide for GHC API clients for the new "multiple home units" feature? In particular, I have the following two functions in my code that used to interact with related features of GHC: addUnit :: UnitInfo -> HscEnv -> HscEnv addUnit unitInfo@GenericUnitInfo{..}<mailto:unitInfo@GenericUnitInfo%7b..%7d> = modifyUnitState $ \us -> us { packageNameMap = addToUFM (packageNameMap us) unitPackageName unitId , unitInfoMap = M.insert unitId unitInfo $ unitInfoMap us } registerModule :: (GhcMonad m) => ModDetails -> ModIface -> m () registerModule details iface = modifySession $ extendHpt . addModule where hmi = HomeModInfo iface details Nothing mod = mi_module iface modOrig = ModOrigin (Just True) [] [] True addModule = modifyUnitState $ \us -> us { moduleNameProvidersMap = M.insert (moduleName mod) (M.singleton mod modOrig) $ moduleNameProvidersMap us } extendHpt env = env { hsc_unit_env = let ue = hsc_unit_env env in ue { ue_hpt = addHomeModInfoToHpt hmi (hsc_HPT env) } } I implemented these using the following utility function: modifyUnitState :: (UnitState -> UnitState) -> HscEnv -> HscEnv modifyUnitState f env = env { hsc_unit_env = let ue = hsc_unit_env env in ue { ue_units = f (ue_units ue) } } With the recent changes to GHC, `modifyUnitState` doesn't work anymore because there is no single `UnitEnv` in the `HscEnv`. I tried updating the `HomeUnitEnv` of the current unit: modifyUnitState :: (UnitState -> UnitState) -> HscEnv -> HscEnv modifyUnitState f env = env { hsc_unit_env = let ue = hsc_unit_env env in ue_updateHomeUnitEnv f' (ue_currentUnit ue) ue } where f' hue = let units = homeUnitEnv_units hue in hue { homeUnitEnv_units = f units } but this leads to a panic: GHC version 9.5.20220613: Unit unknown to the internal unit environment unit (cortex-prim) pprInternalUnitMap main (flags: main, Just main) -> Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in ghc-lib-0.20220613-HQTH0nHhxeOCnJy5jYkZiX:GHC.Utils.Panic pprPanic, called at compiler/GHC/Unit/Env.hs:450:14 in ghc-lib-0.20220613-HQTH0nHhxeOCnJy5jYkZiX:GHC.Unit.Env ue_findHomeUnitEnv, called at compiler/GHC/Unit/Env.hs:394:48 in ghc-lib-0.20220613-HQTH0nHhxeOCnJy5jYkZiX:GHC.Unit.Env ue_unitFlags, called at compiler/GHC/Driver/Env.hs:421:18 in ghc-lib-0.20220613-HQTH0nHhxeOCnJy5jYkZiX:GHC.Driver.Env hscSetActiveUnitId, called at compiler/GHC/Driver/Env.hs:416:34 in ghc-lib-0.20220613-HQTH0nHhxeOCnJy5jYkZiX:GHC.Driver.Env hscSetActiveHomeUnit, called at compiler/GHC/Driver/Make.hs:1853:15 in ghc-lib-0.20220613-HQTH0nHhxeOCnJy5jYkZiX:GHC.Driver.Make What is the new way of registering a new unit or new module with GHC? Thanks, Gergo This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

3 2

Re: GHC code size
by Ben Gamari 15 Jun '22

15 Jun '22

Rodrigo Mesquita <r.mesquita(a)campus.fct.unl.pt> writes: > The visualisation is very cool. I’m left wondering: > > - What triggered this “explosion” in 2012? That is a good question. I'll admit, I'm not entirely sure as I myself only really started contributing to GHC in 2012. > - Do we have statistics on the number of contributors over time? > Yes, we usually report these during the "State of the compiler" talk that is given during the Haskell Implementor's Workshop. I use this script [1] to generate these. It's current output is: "1 year ago" 768 71 "2 year ago" 695 73 "3 year ago" 611 84 "4 year ago" 532 79 "5 year ago" 467 65 "6 year ago" 403 64 "7 year ago" 340 63 "8 year ago" 272 68 "9 year ago" 223 49 "10 year ago" 199 24 Where: * the first column is the beginning of the measured period * the second is the total number of unique contributors in GHC at the end of that period * the third is the number of *new* contributors during that period Cheers, - Ben [1] https://gitlab.haskell.org/bgamari/ghc-utils/-/blob/master/analytics/new-co…

1 0