Update ghc-9.0.1 support

[jneira]

• Update stack dependencies and add ourmolu, floskell formatters and class, refine imports plugins
• Enable shake-bench for stack and ghc-9.0.1
• Use hie-bios master Use last hie-bios
• Clean up cabal-ghc901.project
• Make progress towards Support for GHC-9.0 #297

[pepeiborra]

what does this do?

[jneira]

It is the equivalent to do -w ghc-9.0.1 or --with-compiler ghc-9.0.1, make the build use that compiler executable

[pepeiborra]

is there an upstream issue to upload this to Hackage?

[jneira]

I've commented in the mentioned pr about: haskell/hie-bios#300 (comment)

[fendor]

Release is done

[jneira]

the stack build is failing with

hls-refine-imports-plugin        > /root/build/plugins/hls-refine-imports-plugin/src/Ide/Plugin/RefineImports.hs:52:1: error:
hls-refine-imports-plugin        >     Could not load module ‘TcRnMonad’
hls-refine-imports-plugin        >     It is a member of the hidden package ‘ghc-9.0.1’.
hls-refine-imports-plugin        >     Perhaps you need to add ‘ghc’ to the build-depends in your .cabal file.
hls-refine-imports-plugin        >     Use -v (or `:set -v` in ghci) to see a list of the files searched for.
hls-refine-imports-plugin        >    |
hls-refine-imports-plugin        > 52 | import           TcRnMonad                            (initTcWithGbl,
hls-refine-imports-plugin        >    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

--  While building package hls-refine-imports-plugin-1.0.0.1 (scroll up to its section to see the error) using:
      /root/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_3.4.0.0_ghc-9.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-3.4.0.0 build lib:hls-refine-imports-plugin --ghc-options " -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1

Exited with code exit status 1

CircleCI received exit code 1

but the .cabal file has ghc as dependency:

haskell-language-server/plugins/hls-refine-imports-plugin/hls-refine-imports-plugin.cabal

Lines 16 to 31 in a800b9d

	library
	exposed-modules: Ide.Plugin.RefineImports
	hs-source-dirs: src
	build-depends:
	, aeson
	, base >=4.12 && <5
	, containers
	, deepseq
	, ghc
	, ghcide ^>=1.4
	, hls-explicit-imports-plugin ^>=1.0.0.1
	, hls-graph
	, hls-plugin-api >=1.1 && <1.3
	, lsp
	, text
	, unordered-containers

[fendor]

the stack build is failing with

hls-refine-imports-plugin        > /root/build/plugins/hls-refine-imports-plugin/src/Ide/Plugin/RefineImports.hs:52:1: error:
hls-refine-imports-plugin        >     Could not load module ‘TcRnMonad’
hls-refine-imports-plugin        >     It is a member of the hidden package ‘ghc-9.0.1’.
hls-refine-imports-plugin        >     Perhaps you need to add ‘ghc’ to the build-depends in your .cabal file.
hls-refine-imports-plugin        >     Use -v (or `:set -v` in ghci) to see a list of the files searched for.
hls-refine-imports-plugin        >    |
hls-refine-imports-plugin        > 52 | import           TcRnMonad                            (initTcWithGbl,
hls-refine-imports-plugin        >    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

--  While building package hls-refine-imports-plugin-1.0.0.1 (scroll up to its section to see the error) using:
      /root/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_3.4.0.0_ghc-9.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-3.4.0.0 build lib:hls-refine-imports-plugin --ghc-options " -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1

Exited with code exit status 1

CircleCI received exit code 1

but the .cabal file has ghc as dependency:

haskell-language-server/plugins/hls-refine-imports-plugin/hls-refine-imports-plugin.cabal

Lines 16 to 31 in a800b9d

	library
	exposed-modules: Ide.Plugin.RefineImports
	hs-source-dirs: src
	build-depends:
	, aeson
	, base >=4.12 && <5
	, containers
	, deepseq
	, ghc
	, ghcide ^>=1.4
	, hls-explicit-imports-plugin ^>=1.0.0.1
	, hls-graph
	, hls-plugin-api >=1.1 && <1.3
	, lsp
	, text
	, unordered-containers

Looks like this is not depending on ghc-api-compat, and ghc 9.0 does not expose TcRnMonad anymore

[jneira]

refineImports was disabled by flags for cabal (but the package was not commented out) 🤦
well as @fendor has got to compile all of them i am gonna touch them the less possible

[jneira]

Now it is failing with:

src/Control/Concurrent/Strict.hs:2:6: error:
Error:     Ambiguous occurrence ‘modifyVar'’
    It could refer to
       either ‘Control.Concurrent.Extra.modifyVar'’,
              imported from ‘Control.Concurrent.Extra’ at src/Control/Concurrent/Strict.hs:7:1-72
           or ‘Control.Concurrent.Strict.modifyVar'’,
              defined at src/Control/Concurrent/Strict.hs:15:1
  |
2 |     (modifyVar', modifyVarIO'
  |      ^^^^^^^^^^

I think it is due the recent release of the extra library, aiiiins

[jneira]

I am afraid we cant use hlint-3.2.* and the last extra lib version (@ndmitchell set a upper bound to exclude it https://hackage.haskell.org/package/hlint-3.2.7/revision/1.cabal)

 [42 of 59] Compiling Hint.Fixities    ( src/Hint/Fixities.hs, dist/build/Hint/Fixities.o, dist/build/Hint/Fixities.dyn_o )

src/Hint/Fixities.hs:65:38: error:
Error:     Ambiguous occurrence ‘!?’
    It could refer to
       either ‘Data.List.Extra.!?’,
              imported from ‘Data.List.Extra’ at src/Hint/Fixities.hs:22:1-22
           or ‘Data.Map.!?’,
              imported from ‘Data.Map’ at src/Hint/Fixities.hs:23:1-15
              (and originally defined in ‘Data.Map.Internal’)
   |
65 |     case compareFixity <$> (fixities !? occNameString lop) <*> (fixities !? occNameString rop) of
   |        

[jneira]

i know add new definitions does not suppose bump up the breaking api version following pvp but if they clash with widely used defs as Data.Map, i think it had to have been extra-1.8 imho

[ndmitchell]

@jneira - I think you're right - had I realised that extra was going to break as many things as it did, I'd have definitely made it 1.8. However, I was completely unaware in advance, and now the choice is whether to yank 1.7.10 and upload 1.8, and I suspect at that now that's just adding more hassle? But happy to be convinced otherwise. Sorry!

[jneira]

no worries, it is hard to know in advance where defs are being shadowed if the lib itself does no use them
tbh if client code uses qualified imports adding new defs should not break panything
yeah I think it can be kept as is, if a serious bug fix in hlint needs to be backported a new release can be still done