8.8.x change in lookupModule / findModule semantics?

Tseen She ts33n.sh3 at gmail.com
Thu Feb 27 14:50:39 UTC 2020


On Thu, 27 Feb 2020 at 11:40, Daniel Gröber <dxld at darkboxed.org> wrote:
> You know, it does look like you're implementing in importsOnly is very
> simmilar to ghc's internal getPreprocessedImports

Very likely :-) but if it's not exported I am stuck with the workaround.

. While that function
> isn't exported it's just a simple wrapper around HeaderInfo.getImports
> which is. You might want to use that API instead or is there a reason you
> had to reimplement all of it?

getImports only returns located module names, but I need to recover the
source code with module definition, pragmas, and imports, so that I can
typecheck it (actually I just need to run namer, but that isn't exposed as
a separate phase and typechecking basically isn't anything more than namer
when there is nothing in the file except imports).

Just to be clear though, there is absolutely no problem with the
importsOnly code so much as I'm aware, although I'd be happy to throw it
away if this was made available inside ghc :-)

> Anyways, looking at the code for parseModule as long as the ModSummary you
> pass in has ms_hspp_buf set it should use the buffer instead of the
> file.

Yes, I agree. That function is fine. Using debug tracing, I can confirm
that the ms_hspp_buf of a ModSummary has my in-memory version: I have
isolated the problem to a change in behaviour in the next line:
typecheckModule.


> typecheckModule will just use the ParsedSource parseModule produced so it
> shouldn't do any more file reading.

This is where I am not so sure. I am fairly certain that something has
broken in the typechecking line. I will try again with debug tracing to
confirm what the ParsedSource looks like.


> > As to the relation between importsOnly and lookupModule / findModule,
they
> > are independent.
>
> I'm not actually seeing any calls to {lookup,find}Module in your code so
> it's very hard to say if the behaviour changed. Do you have a reproducer
> for that?


That's because it is in a different branch than the in-memory stuff. I am
more or less getting a problem / regression with this code:

  let target = GHC.Target (GHC.TargetModule mn) False Nothing
  GHC.removeTarget $ TargetModule (traceShow (showGhc mn) mn)
  GHC.addTarget target
  _ <- GHC.load $ GHC.LoadUpTo mn
  m <- GHC.lookupModule mn Nothing

And in my WIP branch
https://gitlab.com/tseenshe/hsinspect/-/blob/wip/ghc882/library/HsInspect/Imports.hs#L38

BTW, if you can point me to something in ghc that does inferModuleName then
that'd be useful in several places.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200227/d36ca4a1/attachment.html>


More information about the ghc-devs mailing list