haskell / haskell-language-server

Official haskell ide support via language server (LSP). Successor of ghcide & haskell-ide-engine.
Apache License 2.0
2.65k stars 354 forks source link

Explicit Records Plugin's (in some scenarios) codeAction doesn't work #3559

Open joyfulmantis opened 1 year ago

joyfulmantis commented 1 year ago

Your environment

Which OS do you use? Fedora 38

Which version of GHC do you use, and how did you install it? 9.4.4 from GHCup

Which LSP client (editor/plugin) do you use? VS Code 1.77.3+vscode-haskell

Which version of HLS do you use and how did you install it? hls-1.10.0.0 from GHCup

Have you configured HLS in any way (especially: a hie.yaml file)? no

Steps to reproduce

I can reproduce this bug in VS Code with the following code by clicking on the record wildcards and then following the code action to expand them.

{-# LANGUAGE RecordWildCards #-}
{-# LANGUAGE NamedFieldPuns #-}
{-# LANGUAGE OverloadedRecordDot #-}

data Happy = Happy {name :: String, age :: Int, happy :: Bool}

main :: IO ()
main = do 
    putStrLn test4

test1 Happy {..}= name

test4 = name man

man :: Happy
man = Happy {name = "Happy", age = 1, happy = True}

Expected behaviour

I expect the codeAction to modify the code.

Actual behaviour

However, nothing happens.

Debug information

I have traced the messages between the hls server and vscode, and the codeAction seems to be fine, but for some reason it won't execute.

Result: [
    {
        "edit": {
            "changes": {
                "file:///[retracted]/Test.hs": [
                    {
                        "newText": "Happy {name}",
                        "range": {
                            "end": {
                                "character": 16,
                                "line": 10
                            },
                            "start": {
                                "character": 6,
                                "line": 10
                            }
                        }
                    }
                ]
            }
        },
        "kind": "refactor.rewrite",
        "title": "Expand record wildcard"
    }
]

This is especially puzzling because small changes in the program cause it to work, just this specific code doesn't. For example, slightly modifying it so that test1 and test4 switch places causes it to work.

{-# LANGUAGE RecordWildCards #-}
{-# LANGUAGE NamedFieldPuns #-}
{-# LANGUAGE OverloadedRecordDot #-}

data Happy = Happy {name :: String, age :: Int, happy :: Bool}

main :: IO ()
main = do 
    putStrLn test4

test4 = name man

test1 Happy {..} = name

man :: Happy
man = Happy {name = "Happy", age = 1, happy = True}

Looking at the codeAction that works, it is almost identical.

Result: [
    {
        "edit": {
            "changes": {
                "file://[retracted]/Test.hs": [
                    {
                        "newText": "Happy {name}",
                        "range": {
                            "end": {
                                "character": 16,
                                "line": 12
                            },
                            "start": {
                                "character": 6,
                                "line": 12
                            }
                        }
                    }
                ]
            }
        },
        "kind": "refactor.rewrite",
        "title": "Expand record wildcard"
    }
]
July541 commented 1 year ago

Ping @ozkutuk as the code owner

ozkutuk commented 1 year ago

This seems pretty interesting; it works as expected on Neovim (via native LSP), whereas I can indeed replicate the issue on VSCode, using the same HLS build on both. Which makes me think, could this possibly be an issue with vscode-haskell?

konn commented 7 months ago

I've also been hit by this bug. Environment:

soulomoon commented 7 months ago

This seems pretty interesting; it works as expected on Neovim (via native LSP), whereas I can indeed replicate the issue on VSCode, using the same HLS build on both. Which makes me think, could this possibly be an issue with vscode-haskell?

Interesting bug, I wonder if vscode-Haskell doing more than just wrapping up edits on this?