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.e...@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ő <ge...@erdi.hu>
> Sent: Sunday, June 19, 2022 12:32 PM
> To: Erdi, Gergo <gergo.e...@sc.com>
> Cc: GHC Devs <ghc-devs@haskell.org>; Montelatici, Raphael Laurent
> <raphael.montelat...@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.
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
