HLS 1.5 appears to not handle hs-boot files correctly

[sheaf]

With HLS 1.5 (using GHC 9.0.1), using the VS Code extension on Windows 10, I'm getting errors when running HLS on the GHC codebase. These errors seem to be caused by a problem loading an hi-boot interface file.

Running HLS on GHC commit f8c1c549bbb02cb0a943a9ae49dee922c96d85c4, I'm getting the following errors:

Show/hide interface file errors

GHC.Types.ForeignCall:

• No instance for (Eq (GenUnit UnitId))
    arising from the third field of ‘StaticTarget’ (type ‘Maybe Unit’)
  Possible fix:
    use a standalone 'deriving instance' declaration,
      so you can specify the instance context yourself
• When deriving the instance for (Eq CCallTarget)

• No instance for (Data (GenUnit UnitId))
    arising from the third field of ‘StaticTarget’ (type ‘Maybe Unit’)
  Possible fix:
    use a standalone 'deriving instance' declaration,
      so you can specify the instance context yourself
• When deriving the instance for (Data CCallTarget)

[...]

GHC.Types.Name:

• Can't find interface-file declaration for variable isInteractiveModule
    Probable cause: bug in .hi-boot file, or inconsistent .hi file
    Use -ddump-if-trace to get an idea of which file caused the error
• In the second argument of ‘(||)’, namely
    ‘isInteractiveModule mod’
  In the expression: from == mod || isInteractiveModule mod
  In an equation for ‘nameIsLocalOrFrom’:
      nameIsLocalOrFrom from name
        | Just mod <- nameModule_maybe name
        = from == mod || isInteractiveModule mod
        | otherwise = True

[...]

GHC.Unit.Info:

• Can't find interface-file declaration for type constructor or class UnitKey
    Probable cause: bug in .hi-boot file, or inconsistent .hi file
    Use -ddump-if-trace to get an idea of which file caused the error
• In the first argument of ‘GenUnitInfo’, namely ‘UnitKey’
  In the type ‘GenUnitInfo UnitKey’
  In the type declaration for ‘UnitKeyInfo’

These all seem to do with failing to load the hi-boot file for GHC.Unit.Types.

I have cleared the ghcide cache as well as the _hie_bios folder, and the error persists. Switching back to HLS 1.4 immediately fixes the problem.

[jneira]

Many thanks for reporting the bug quickly, @mpickering just has reported it in irc.
He mentioned that maybe it could be related with the presence of hs-boot files, does it fit your observations?

[sheaf]

Yes, in the case I reported it seems related to the GHC.Unit.Types.hs-boot file.

[jneira]

Ok, there are at least two tests in ghcide about hs-boot files

haskell-language-server/ghcide/test/exe/Main.hs

Lines 437 to 481 in a03013c

	, testSessionWait "cyclic module dependency with hs-boot" $ do
	let contentA = T.unlines
	[ "module ModuleA where"
	, "import {-# SOURCE #-} ModuleB"
	]
	let contentB = T.unlines
	[ "{-# OPTIONS -Wmissing-signatures#-}"
	, "module ModuleB where"
	, "import ModuleA"
	-- introduce an artificial diagnostic
	, "foo = ()"
	]
	let contentBboot = T.unlines
	[ "module ModuleB where"
	]
	_ <- createDoc "ModuleA.hs" "haskell" contentA
	_ <- createDoc "ModuleB.hs" "haskell" contentB
	_ <- createDoc "ModuleB.hs-boot" "haskell" contentBboot
	expectDiagnostics [("ModuleB.hs", [(DsWarning, (3,0), "Top-level binding")])]
	, testSessionWait "correct reference used with hs-boot" $ do
	let contentB = T.unlines
	[ "module ModuleB where"
	, "import {-# SOURCE #-} ModuleA()"
	]
	let contentA = T.unlines
	[ "module ModuleA where"
	, "import ModuleB()"
	, "x = 5"
	]
	let contentAboot = T.unlines
	[ "module ModuleA where"
	]
	let contentC = T.unlines
	[ "{-# OPTIONS -Wmissing-signatures #-}"
	, "module ModuleC where"
	, "import ModuleA"
	-- this reference will fail if it gets incorrectly
	-- resolved to the hs-boot file
	, "y = x"
	]
	_ <- createDoc "ModuleB.hs" "haskell" contentB
	_ <- createDoc "ModuleA.hs" "haskell" contentA
	_ <- createDoc "ModuleA.hs-boot" "haskell" contentAboot
	_ <- createDoc "ModuleC.hs" "haskell" contentC
	expectDiagnostics [("ModuleC.hs", [(DsWarning, (3,0), "Top-level binding")])]

But they did not catch the bug, maybe cause they dont reproduce the bug context

Will try to reproduce with ghcup-hs, it is a relatively small project and contains at least one hs-boot file

[wz1000]

This issue was introduced by ab46fe8 , which changed the logic to compute the GHC session with dependencies for a file.

The GetDependencies rule used to add a dependency edge between a module and its boot module. Now that GetModIface doesn't use that rule anymore, this edge no longer exists, resulting the above error.

[pepeiborra]

Thanks for the diagnosis @wz1000, I think you are 100% correct. Bummer!

Is anyone able to contribute a test case and a fix? If not, I'll take a look this weekend or next week.

[jneira]

The ci workflow of the release commit for ghc-9.0.1 executed tests succesfully:

    cyclic module dependency with hs-boot:                                                                OK (1.08s)
    correct reference used with hs-boot:                                                                  OK (1.22s)

Tests dont check the absence of error diagnostics explicitly, so maybe that is the cause they did not catch the bug