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
Source level package qualified imports `import "foo" A` interpret "foo" as a package name.
377
+
378
+
When one manually builds a `RawPkgQual` for an `InteractiveImportDecl` one can get away with using a unit-id, but only for external (i.e. not home) units.
379
+
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.
380
+
```
381
+
| otherwise
382
+
-> OtherPkg (UnitId pkg_fs)
383
+
-- not really correct as pkg_fs is unlikely to be a valid unit-id but
384
+
-- we will report the failure later...
385
+
```
386
+
387
+
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.
388
+
TODO: report this upstream.
389
+
390
+
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.
391
+
392
+
See issue #288 for what can we do for users at the repl.
0 commit comments