Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More work around next ghc-9.2.1 support #2587

Merged
merged 5 commits into from
Jan 14, 2022
Merged

More work around next ghc-9.2.1 support #2587

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
8922449
Enable class-hierarchy for 9.2.1
jneira Jan 14, 2022
8d5c15a
Add module-name plugin to tests
jneira Jan 14, 2022
b5b7538
Update docs status
jneira Jan 14, 2022
8c366d6
Include module plugin via flags
jneira Jan 14, 2022
a7a9b09
Module name does not compile for ghc-9.2.1
jneira Jan 14, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions .github/workflows/test.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -210,6 +210,10 @@ jobs:
name: Test hls-hlint-plugin test suite
run: cabal test hls-hlint-plugin --test-options="$TEST_OPTS" || cabal test hls-hlint-plugin --test-options="$TEST_OPTS" || LSP_TEST_LOG_COLOR=0 LSP_TEST_LOG_MESSAGES=true LSP_TEST_LOG_STDERR=true cabal test hls-hlint-plugin --test-options="$TEST_OPTS"

- if: matrix.test && matrix.ghc != '9.2.1'
name: Test hls-module-name-plugin test suite
run: cabal test hls-module-name-plugin --test-options="$TEST_OPTS" || cabal test hls-module-name-plugin --test-options="$TEST_OPTS" || LSP_TEST_LOG_COLOR=0 LSP_TEST_LOG_MESSAGES=true LSP_TEST_LOG_STDERR=true cabal test hls-module-name-plugin --test-options="$TEST_OPTS"

- if: matrix.test && matrix.ghc != '9.2.1'
name: Test hls-alternate-number-format-plugin test suite
run: cabal test hls-alternate-number-format-plugin --test-options="$TEST_OPTS" || cabal test hls-alternate-number-format-plugin --test-options="$TEST_OPTS" || LSP_TEST_LOG_COLOR=0 LSP_TEST_LOG_MESSAGES=true LSP_TEST_LOG_STDERR=true cabal test hls-alternate-number-format-plugin --test-options="$TEST_OPTS"
Expand Down
1 change: 0 additions & 1 deletion cabal-ghc921.project
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,7 +55,6 @@ constraints:
+ignore-plugins-ghc-bounds
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@jneira jneira Jan 14, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

-alternateNumberFormat
-brittany
-callhierarchy
-class
-eval
-haddockComments
Expand Down
2 changes: 1 addition & 1 deletion docs/supported-versions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ The current support for different GHC versions is given in the following table.

| GHC version | Last supporting HLS version | Deprecation status |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- |
| 9.2.0 | [not supported](https://github.com/haskell/haskell-language-server/issues/2179) yet | |
| 9.2.0 | incoming [partial](https://github.com/haskell/haskell-language-server/issues/2179) | |
| 9.0.1 | [current](https://github.com/haskell/haskell-language-server/releases/latest) ([partial](https://github.com/haskell/haskell-language-server/issues/297)) | |
| 8.10.7 | [current](https://github.com/haskell/haskell-language-server/releases/latest) | |
| 8.10.6 | [current](https://github.com/haskell/haskell-language-server/releases/latest) | will be deprecated after LTS and HLS full support for ghc-9.0 |
Expand Down
4 changes: 2 additions & 2 deletions haskell-language-server.cabal
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -211,7 +211,7 @@ common class
cpp-options: -Dclass

common callHierarchy
if flag(callHierarchy) && (impl(ghc < 9.2.1) || flag(ignore-plugins-ghc-bounds))
if flag(callHierarchy)
build-depends: hls-call-hierarchy-plugin ^>=1.0.0.0
cpp-options: -DcallHierarchy

Expand Down Expand Up @@ -256,7 +256,7 @@ common hlint
cpp-options: -Dhlint

common moduleName
if flag(moduleName)
if flag(moduleName) && (impl(ghc < 9.2.1) || flag(ignore-plugins-ghc-bounds))
build-depends: hls-module-name-plugin ^>=1.0.0.0
cpp-options: -DmoduleName

Expand Down