Sorry for the spam, but I think this is definitely a bug/regression in ghc-8.8.1 (still present in 8.8.3).

I don't know which commit introduced the problem, but it seems that getModSummary is no longer reporting the correct ms_hspp_opts, at least for an in-memory file but it could also be for a file on disk as well (I haven't excluded that as a possibility).

Here is my workaround

#if MIN_VERSION_GLASGOW_HASKELL(8,8,1,0)
  dflags <- GHC.getSessionDynFlags
  let file = GHC.ms_hspp_file modSum
  buf <- case GHC.ms_hspp_buf modSum of
        Nothing -> liftIO $ hGetStringBuffer file
        Just b -> pure b
  let pragmas = getOptions dflags buf file
  (dflags', _, _) <- parseDynamicFilePragma dflags pragmas
  let modSum' = modSum { GHC.ms_hspp_opts = dflags' }
#else
  let modSum' = modSum
#endif



On Thu, 27 Feb 2020 at 15:18, Tseen She <ts33n.sh3@gmail.com> wrote:
and it looks like the language pragmas slurped from the in-memory buffer is empty

  tmod <- GHC.typecheckModule (trace (showGhc . GHC.extensions $ GHC.ms_hspp_opts modSum) pmod)

gives me [] on 8.8 but is [Off ImplicitPrelude, On PackageImports] on 8.6.5... that looks like an 8.8 regression to me.


On Thu, 27 Feb 2020 at 15:02, Tseen She <ts33n.sh3@gmail.com> wrote:
Quick followup with trace debugging:

On Thu, 27 Feb 2020 at 14:50, Tseen She <ts33n.sh3@gmail.com> wrote:
> 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.

I can confirm that a showPpr on `pm_parsed_source` has the in-memory version.

But, perhaps, the problem might be that pragmas are not carried over? In my test the "importsOnly" version of the file is preserving two LANGUAGE pragmas that are necessary in order to parse the imports section (one of my tests uses PackageImports). Just a guess, but does 8.8.x now require more manual passing of the dynflags? This seems like a regression / bug to me but I'd be willing to workaround it if it is an intentional behaviour change.