Hi, On Thu, Feb 27, 2020 at 08:02:16AM +0000, Tseen She wrote:
I think we might be mixing up the two threads here, please let me know if I've misunderstood
Ah yes, I was reading both threads and ended up replying to the wrong one :)
so I'll respond as if this was in response to the thread about in-memory buffers: the function you've hightlighted is working as intended (thanks for clarifying the API change, I had to work that out myself and was just guessing) and produces the minimal buffer that is then used by the next function.
You know, it does look like you're implementing in importsOnly is very simmilar to ghc's internal getPreprocessedImports. 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? 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. The code will eventually call `hscParse'` which has: let src_filename = ms_hspp_file mod_summary maybe_src_buf = ms_hspp_buf mod_summary -------------------------- Parser ---------------- -- sometimes we already have the buffer in memory, perhaps -- because we needed to parse the imports out of it, or get the -- module name. buf <- case maybe_src_buf of Just b -> return b Nothing -> liftIO $ hGetStringBuffer src_filename typecheckModule will just use the ParsedSource parseModule produced so it shouldn't do any more file reading.
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? --Daniel