You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Only import inner scope for module we are stopped at.
At the start of a session we import:
- exported symbols from Prelude
- instances from loaded Debug View modules
- instances from debugeee home units modules
(we were importing their inner scope before).
The latter two are so DebugView orphans are in scope.
During an eval, if stopped at a breakpoint, we also import
the inner scope of the breakpoint module.
Imports made by the user at the REPL are as before:
preserved across stops, only for exported symbols.
A package-qualified module import will be looked up directly in the exposed
583
-
packages, IGNORING the home units modules.
584
-
585
-
This can lead to two scenarios:
584
+
Package qualified imports have a quirky behaviour: the source string qualifier gets converted into a `PkgQual` on the way, which can be one of these two:
585
+
- `ThisPkg unitId` interpreted as a home unit
586
+
- `OtherPkg unitId` interpreted as an external package
586
587
587
-
1) a package-import of a loaded unit fails, because that unit, despite being
588
-
loaded, is not installed
588
+
We get each under these conditions:
589
+
- ThisPkg
590
+
- qualifier is the literal "this" or the **package name** of the active home unit or any of its home unit dependencies.
591
+
- OtherPkg
592
+
- qualifier is the **package name** of a non-hidden external unit which exports the module we are importing.
593
+
- None of the above apply, and the qualifier itself is interpreted as a `UnitId`.
594
+
When choosing between multiple units that satisfy a condition, the first found is committed to.
589
595
590
-
2) a package-import of a loaded unit succeeds, because a unit with the same
591
-
name (but not necessarily the same unit-id!), is installed.
596
+
The upshot is that `UnitId`s normally only work as qualifiers for external packages, unless you change the package names of home units as described in Note [ Ambiguous Package Qualified Imports Workaround ].
592
597
593
-
The second case can result in subtly wrong interactive sessions, where the
598
+
At the same time doing a PackageImport with a plain PackageName can succeed while resolving to an installed unit while we meant one of the loaded units, resulting in subtly wrong interactive sessions, where the
594
599
package-qualified imported module shadows the loaded module. Perhaps GHC could
595
600
warn about this. Cabal-repl and ghci also suffer from this subtle interaction.
596
601
597
602
In light of this, when the debugger imports the `haskell-debugger-view` modules,
598
603
it is imperative that if the `haskell-debugger-view` unit is in the home units
599
604
(e.g. if `haskell-debugger-view` is listed in the cabal.project, like it is in
600
-
the debugger tree), we do not use a package-qualified import.
605
+
the debugger tree), we rely on Note [ Ambiguous Package Qualified Imports Workaround ].
601
606
602
607
On the other hand, if the `haskell-debugger-view` package is not in the
603
608
home-units, we *should* package-qualify it to make sure we reference the right
@@ -623,10 +628,6 @@ cleanupInterp = do
623
628
sendMessage i Shutdown
624
629
pureInterpPending
625
630
626
-
--| WARNING: callback is not to be used from other threads.
627
-
withUnliftGhc:: ((Ghcb->IOb) ->IOa) ->Ghca
628
-
withUnliftGhc k = reifyGhc $\ s -> k (flip reflectGhc s)
Source level package qualified imports `import "foo" A` interpret "foo" as a package name.
389
+
390
+
When one manually builds a `RawPkgQual` for an `ImportDecl` one can get away with using a unit-id, but only for external (i.e. not home) units.
391
+
That it works does not seem entirely intended (see quoted snippet below), the code is in `renamePkgQual`: If a package qualifier is not found among packages it's looked up as an external unit. This is already in the code path for `OtherPkg` though, which is why Home Units are excluded.
392
+
```
393
+
| otherwise
394
+
-> OtherPkg (UnitId pkg_fs)
395
+
-- not really correct as pkg_fs is unlikely to be a valid unit-id but
396
+
-- we will report the failure later...
397
+
```
398
+
399
+
Home units will only be found if the qualifier matches their dflags' `thisPackageName`. However that's bugged because the lookup doesn't bother considering there can be multiple units in the same package (library, sublibraries and exe units), and just picks the first found, leading to an import error if e.g. the library unit is picked but the module was in the exe one.
400
+
Related GHC issue: https://gitlab.haskell.org/ghc/ghc/-/issues/24227
401
+
402
+
Turns out that the package name of a home unit is pretty meaningless though, so we can update the dflags to replace it with anything that's actually unique so we can dodge the bug.
403
+
404
+
Another stumbling block is that the `IIDecl` mode of an `InteractiveImport` does not allow importing hidden modules, but again for home units we can alter the DynFlags so all modules are exposed.
405
+
406
+
See issue #288 for what can we do for users at the repl.
0 commit comments