Closed konn closed 8 months ago
Thank you for your bug report. Interesting case, I’ll take a look later
I can not repro use your setting. Could you provide me with a example package in git so I can investigate. @konn
I can reproduce now. It seems the type variable s
is included in the newtype location in hieAst when deriving.
Node@hello.hs:59:10-16: Source: From source
{(annotations: {(NewtypeStrategy, DerivStrategy)}), (types: []),
(identifier info: {(name s, Details: Nothing {type variable binding with scope: LocalScope hello.hs:59:27-42 , type variable scopes:})})}
possible fix would be walk to along with the lexed source: https://github.com/haskell/haskell-language-server/pull/3958#issuecomment-1898180693, to prevent the generated token from appearing
shoud be fixed by https://github.com/haskell/haskell-language-server/pull/3958.
Your environment
Which OS do you use? macOS Sonoma14.2.1(23C71)
Which version of GHC do you use and how did you install it? GHC 9.2.8 via GHCup
How is your project built (alternative: link to the project)? By
cabal-install
. This can happen in any project, but seelinear-extra
.Which LSP client (editor/plugin) do you use? VSCode
Which version of HLS do you use and how did you install it? 2.6.0.0, via ghcup-vanilla-0.0.8.
Have you configured HLS in any way (especially: a
hie.yaml
file)? No. Auto Detection.Steps to reproduce
Adds a standalone deriving clause with explicit deriving strategy with Semantic Tokens enabled.
Example. Consider the following:
In above,
newtype
is treated as keyword correctly:Next, make
Hashable
instance deriving standalone:Then
newtype
is rendered differently!Changing
newtype
toanyclass
gives the same effect. If we change it tovia LocAddr_
,via
is rendered correctly.Expected behaviour
Both
newtype
andanyclass
must be treated as keyword.Actual behaviour
Treated as parameter, as above. Here is the token inspection result from VSCode:
Debug information
Here is the trace log of VSCode:
vscode.log