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.

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

complex type variables in hover with GHC 9.2 #2716

Closed
guibou opened this issue Feb 16, 2022 · 5 comments · Fixed by #2828
Closed

complex type variables in hover with GHC 9.2 #2716

guibou opened this issue Feb 16, 2022 · 5 comments · Fixed by #2828
Labels
component: ghcide type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..

Comments

@guibou
Copy link
Collaborator

guibou commented Feb 16, 2022

Type signature in hover with GHC 9.2 are longer what they used to be.

See for example:

image

See the a_aI0wB. With GHC 8.10.7, it was a:

image

Your environment

Which OS do you use:
Linux
Which LSP client (editor/plugin) do you use:
neovim + lsp-config
Describe your project (alternative: link to the project):

Huge proprietary codebase built with bazel with a custom HLS hie setup.

Steps to reproduce

Use hover on a type. However that's not always clear, because sometimes I can observe "short" type variable. In my example, it appen on class and newtype which have type parameters.

Expected behaviour

Type variable should be short. They were used to be named as the type variable in the associated newtype or class.

Actual behaviour

Type variables are long and complex. The starts with the original name, but a noisy suffix is appended.

Include debug information

@guibou guibou added type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc.. status: needs triage labels Feb 16, 2022
@michaelpj
Copy link
Collaborator

It seems likely that something changed in GHC upstream.

@hsyl20
Copy link

hsyl20 commented Feb 23, 2022

The following code looks incorrect:

renderWithContext (defaultSDocContext { sdocSuppressUniques = True }) . ppr

Because of https://gitlab.haskell.org/ghc/ghc/-/commit/8d401e50ce35525dcdc6a21fcf952c3cbf3a72d4, a name is always printed with its unique except with "user" style, but defaultSDocContext defaults to use "dump" style.

Something like this should fix it:

renderWithContext (defaultSDocContext { sdocSuppressUniques = True, sdocStyle = defaultUserStyle }) . ppr

@Kleidukos
Copy link
Member

Well, that's a golden test that's just waiting to get written. :)

michaelpj added a commit to michaelpj/haskell-language-server that referenced this issue Mar 1, 2022
@michaelpj
Copy link
Collaborator

I wrote a failing test, PR incoming.

The following code looks incorrect...

Unfortunately, that's not it. I think the real issue is that we pervasively use showSDocUnsafe, re-exported from ghc, which prints uniques. I don't really know what to do about this, we have dozens of wrappers around various SDoc printing functions, it's somewhat horrifying.

@hsyl20
Copy link

hsyl20 commented Mar 2, 2022

Could you replace all uses of showSDocUnsafe with a call to the following showSDocForUser function which would have better defaults?

showSDocForUser :: SDoc -> String
showSDocForUser = renderWithContext $ defaultSDocContext
  { sdocStyle               = defaultUserStyle
  , sdocCanUseUnicode       = True -- I guess?
  , sdocPrintUnicodeSyntax  = True -- maybe
  , sdocSuppressUniques     = True
  }

michaelpj added a commit that referenced this issue Mar 7, 2022
mergify bot added a commit that referenced this issue Mar 8, 2022
Witnesses #2716.

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: Pepe Iborra <[email protected]>
July541 pushed a commit to July541/haskell-language-server that referenced this issue Mar 30, 2022
Witnesses haskell#2716.

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: Pepe Iborra <[email protected]>
@mergify mergify bot closed this as completed in #2828 Apr 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: ghcide type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants