More work around next ghc-9.2.1 support

[jneira]

• Updating the issue about Support for ghc-9.2.* #2179 i 've noted:
  • hls-class-hierarchy-plugin is being tested for ghc-9.2.1 but it is not included in the executable via flags, this includes it

haskell-language-server/.github/workflows/test.yml

Lines 201 to 203 in 8804cbd

	- if: matrix.test
	name: Test hls-call-hierarchy-plugin test suite
	run: cabal test hls-call-hierarchy-plugin --test-options="$TEST_OPTS" || cabal test hls-call-hierarchy-plugin --test-options="$TEST_OPTS" || LSP_TEST_LOG_COLOR=0 LSP_TEST_LOG_MESSAGES=true LSP_TEST_LOG_STDERR=true cabal test hls-call-hierarchy-plugin --test-options="$TEST_OPTS"

haskell-language-server/cabal-ghc921.project

Lines 54 to 69 in 8804cbd

	haskell-language-server
	+ignore-plugins-ghc-bounds
	-alternateNumberFormat
	-brittany
	-callhierarchy
	-class
	-eval
	-haddockComments
	-hlint
	-moduleName
	-qualifyImportedNames
	-refineImports
	-retrie
	-splice
	-stylishhaskell
	-tactic

• hls-module-name-plugin has a test suite but it not was being tested in ci 🤦, this includes even for ghc-9.2.1, if it does not work, will exclude from that version

• i've updated docs to note we have partial support for ghc-9.2.1 but no release

[michaelpj]

Shouldn't we be able to go back to just turning this flag off and letting cabal pick the ones which say they can be included based on the ghc bounds in the cabal files?

[jneira]

I am afraid we can't, the ghc "bounds" are not a dependency on ghc in build-depends but a specific cabal syntax for conditionals using the current ghc, the condition sets the flag and then comes the solver phase.
For example it is possible to have conditions on ghc version without depending at all on ghc as a library

[jneira]

Maybe we could replace flags with ghc bounds in build-depends (maybe you were thinking on that?) but not all plugins depend on ghc directly but through ghcide and put ghc in its .cabal file that dependency would be "artificial". I would say plugins should depend less directly on ghc (via hie-compat)

[michaelpj]

I meant:

• We have the stylish-haskell flag in haskell-language-server.cabal
• We depend on the stylish-haskell plugin if the flag is on and the GHC version is okay, unless we set the override flag
• Here we're turning off the stylish-haskell flag and setting the override flag.
• So... what if we stop setting either of them? Then the stylish-haskell plugin just won't be enabled because of the GHC version guard, which is what we want, right?

[jneira]

hmm, i think the idea was being able to override the ghc bound withouth changing the .cabal file only the cabal.project and change only the .cabal file when the development is finished and we are about to do the hackage release

so you could override it doing a cabal install from a hackage version if you local environment makes the plugin work somewhat

but maybe it is better to update directly the .cabal file yeah as that use case is in fact very rare, will try it, thanks!

[michaelpj]

I don't know, I'm confused. Maybe we should write down the rationale in the contributing docs too :)

[jneira]

hmm i think the explanation is we can have plugins working in github but no in hackage (due to allow-newers and remote-source-repo in the cabal.project)
so we have to make them not buildables by default for hackage but skip it in the cabal.project
does it make sense?

[jneira]

hls-module-name does not even compile with ghc-9.2.1, sad but good to know
and hls-class-hierarchy-plugin works so 🎉