@@ -94,6 +94,9 @@ import GHC.Platform.Ways
9494import GHC.Data.FastString.Env (emptyFsEnv )
9595#endif
9696
97+ import GHC.Unit.Home.Graph
98+
99+ >>>>>>> ae72129 (Fix hd- view package- qualified imports bypassing home- unit)
97100-- | A debugger action.
98101newtype Debugger a = Debugger { unDebugger :: ReaderT DebuggerState GHC. Ghc a }
99102 deriving ( Functor , Applicative , Monad , MonadIO
@@ -428,11 +431,13 @@ runDebugger l rootDir compDir libdir units ghcInvocation' extraGhcArgs mainFp co
428431 let preludeImp = GHC. IIDecl . GHC. simpleImportDecl $ GHC. mkModuleName " Prelude"
429432 -- dbgView should always be available, either because we manually loaded it
430433 -- or because it's in the transitive closure.
434+ hug <- hsc_HUG <$> getSession
431435 let dbgViewImps
432- -- Using in-memory hs-dbg-view. It's a home-unit, so refer to it directly
433- | hdv_uid == hsDebuggerViewInMemoryUnitId
436+ -- If hs-dbg-view is a home-unit, refer to it directly
437+ -- See Note [Do not package-qualify imports for home units]
438+ | memberHugUnitId hdv_uid hug
434439 = map (GHC. IIModule . mkModule (RealUnit (Definite hdv_uid))) loadedBuiltinModNames
435- -- It's available in a unit in the transitive closure. Resolve it.
440+ -- It's available in an exposed unit in the transitive closure. Resolve it
436441 | otherwise
437442 = map (\ mn ->
438443 GHC. IIDecl (GHC. simpleImportDecl mn)
@@ -507,9 +512,7 @@ add our own `MC.finally cleanupInterp` call which sends the `Shutdown` message
507512to the external interpreter before propagating the exception further (to GHC's
508513`withCleanupSession`, which will now do Nothing because we set `InterpPending`,
509514and beyond).
510- -}
511515
512- {-
513516Note [Must explicitly expose module graph units]
514517~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
515518`interactiveGhcDebugger` is our "current home unit", so its
@@ -533,6 +536,33 @@ An alternative, closer to what ghci does, would be to copy the `packageFlags`
533536from the debuggee units, however doing so doesn't take care of fixing a unitId
534537for dependencies of dependencies.
535538
539+ Note [Do not package-qualify imports for home units]
540+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
541+ A package-qualified module import will be looked up directly in the exposed
542+ packages, IGNORING the home units modules.
543+
544+ This can lead to two scenarios:
545+
546+ 1) a package-import of a loaded unit fails, because that unit, despite being
547+ loaded, is not installed
548+
549+ 2) a package-import of a loaded unit succeeds, because a unit with the same
550+ name (but not necessarily the same unit-id!), is installed.
551+
552+ The second case can result in subtly wrong interactive sessions, where the
553+ package-qualified imported module shadows the loaded module. Perhaps GHC could
554+ warn about this. Cabal-repl and ghci also suffer from this subtle interaction.
555+
556+ In light of this, when the debugger imports the `haskell-debugger-view` modules,
557+ it is imperative that if the `haskell-debugger-view` unit is in the home units
558+ (e.g. if `haskell-debugger-view` is listed in the cabal.project, like it is in
559+ the debugger tree), we do not use a package-qualified import.
560+
561+ On the other hand, if the `haskell-debugger-view` package is not in the
562+ home-units, we *should* package-qualify it to make sure we reference the right
563+ one.
564+
565+ See also #283
536566-}
537567
538568-- | See Note [Shutting down the external interpreter]
0 commit comments