Semantic Tokens treats a standalone deriving strategy as type parameter

[konn]

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 see linear-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.

{
  "haskell.plugin.semanticTokens.globalOn": true,
  "editor.semanticHighlighting.enabled": true
}

Example. Consider the following:

type LocAddr :: Location -> Type
newtype LocAddr s = LocAddr {getLocAddr_ :: LocAddr_}
  deriving (P.Eq, P.Ord)
  deriving newtype (Hashable)

In above, newtype is treated as keyword correctly:

Next, make Hashable instance deriving standalone:

deriving newtype instance Hashable (LocAddr s)

Then newtype is rendered differently!

Changing newtype to anyclass gives the same effect. If we change it to via LocAddr_, via is rendered correctly.

Expected behaviour

Both newtype and anyclass 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

[soulomoon]

Thank you for your bug report. Interesting case, I’ll take a look later

[soulomoon]

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: #3958 (comment), to prevent the generated token from appearing

[soulomoon]

shoud be fixed by #3958.