failed to parse result of calling cabal (better error message)

andrewufrank commented 3 years ago

I get in Problems the message failed to parse result of calling cabal which is hinting an internal problem. The cause was most mundane: the library in the project did not compile and in consequence the executable could not compile - strange enough, the other executable did not produce any error.

Your environment

Output of haskell-language-server --probe-tools or haskell-language-server-wrapper --probe-tools:

haskell-language-server-wrapper --probe-tools
haskell-language-server version: 1.1.0.0 (GHC: 8.10.4) (PATH: /home/frank/.ghcup/bin/haskell-language-server-wrapper-1.1.0) (GIT hash: f1c096927186a93d8e3ccd4fe8385cc1b070350b)
Tool versions found on the $PATH
cabal:          3.4.0.0
stack:          2.5.1
ghc:            8.10.4

Which OS do you use: debian bullseye AMD64

Which lsp-client do you use: vs code

Describe your project (alternative: link to the project):

two executables, a library,

Steps to reproduce

I am not certain that this can be reproduced - I have not seen it in other similar cases.

Expected behaviour

I expect a reasonable error message

Actual behaviour


{
    "resource": "/home/frank/Workspace11/ssg/app/ssgBake.hs",
    "owner": "Haskell (ssg)",
    "severity": 8,
    "message": "Failed to parse result of calling cabal\nBuild profile: -w ghc-8.10.4 -O1\nIn order, the following will be built (use -v for more details):\n - ssg-0.0.4.2 (lib) (file src/Uniform/Docrep.hs changed)\n - ssg-0.0.4.2 (exe:ssgbake) (configuration changed)\nPreprocessing library for ssg-0.0.4.2..\nBuilding library for ssg-0.0.4.2..\n[10 of 23] Compiling Uniform.Docrep   ( src/Uniform/Docrep.hs, /home/frank/.cache/hie-bios/dist-ssg-ccec0eed33d4ea624add0f1a2f74e2f0/build/x86_64-linux/ghc-8.10.4/ssg-0.0.4.2/build/Uniform/Docrep.o, /home/frank/.cache/hie-bios/dist-ssg-ccec0eed33d4ea624add0f1a2f74e2f0/build/x86_64-linux/ghc-8.10.4/ssg-0.0.4.2/build/Uniform/Docrep.dyn_o )\n[12 of 23] Compiling Uniform.Pandoc   ( src/Uniform/Pandoc.hs, /home/frank/.cache/hie-bios/dist-ssg-ccec0eed33d4ea624add0f1a2f74e2f0/build/x86_64-linux/ghc-8.10.4/ssg-0.0.4.2/build/Uniform/Pandoc.o, /home/frank/.cache/hie-bios/dist-ssg-ccec0eed33d4ea624add0f1a2f74e2f0/build/x86_64-linux/ghc-8.10.4/ssg-0.0.4.2/build/Uniform/Pandoc.dyn_o ) [Uniform.Docrep changed]\n[14 of 23] Compiling Lib.MetaPage     ( src/Lib/MetaPage.hs, /home/frank/.cache/hie-bios/dist-ssg-ccec0eed33d4ea624add0f1a2f74e2f0/build/x86_64-linux/ghc-8.10.4/ssg-0.0.4.2/build/Lib/MetaPage.o, /home/frank/.cache/hie-bios/dist-ssg-ccec0eed33d4ea624add0f1a2f74e2f0/build/x86_64-linux/ghc-8.10.4/ssg-0.0.4.2/build/Lib/MetaPage.dyn_o )\n\n\nsrc/Lib/MetaPage.hs:33:37: error:\n    Not in scope: type constructor or class ‘DocLanguage’\n   |\n33 |                         , dyLang :: DocLanguage\n   |                                     ^^^^^^^^^^^\n\nsrc/Lib/MetaPage.hs:48:44: error:\n    Not in scope: type constructor or class ‘IndexEntry’\n   |\n48 |                         , dyDirEntries :: [IndexEntry]\n   |                                            ^^^^^^^^^^\n\nsrc/Lib/MetaPage.hs:49:45: error:\n    Not in scope: type constructor or class ‘IndexEntry’\n   |\n49 |                         , dyFileEntries :: [IndexEntry]\n   |                                             ^^^^^^^^^^\n\nsrc/Lib/MetaPage.hs:70:10: error:\n    Not in scope: type constructor or class ‘Default’\n   |\n70 | instance Default MetaPage where\n   |          ^^^^^^^\n\nsrc/Lib/MetaPage.hs:87:19: error:\n    Not in scope: type constructor or class ‘Options’\n   |\n87 | docyamlOptions :: Options\n   |                   ^^^^^^^\n\nsrc/Lib/MetaPage.hs:90:10: error:\n    Not in scope: ‘fieldLabelModifier’\n   |\n90 |         {fieldLabelModifier = t2s . toLowerStart . s2t . drop 2 }\n   |          ^^^^^^^^^^^^^^^^^^\n\nsrc/Lib/MetaPage.hs:92:10: error:\n    Not in scope: type constructor or class ‘ToJSON’\n   |\n92 | instance ToJSON MetaPage where\n   |          ^^^^^^\n\nsrc/Lib/MetaPage.hs:95:10: error:\n    Not in scope: type constructor or class ‘FromJSON’\n   |\n95 | instance FromJSON MetaPage where\n   |          ^^^^^^^^\n\nsrc/Lib/MetaPage.hs:104:16: error:\n    Not in scope: data constructor ‘Object’\n    |\n104 | parseJSONyaml (Object o) = -- withObject \"person\" $ \\o -> \n    |                ^^^^^^\n\nsrc/Lib/MetaPage.hs:125:12: error:\n    Illegal `..' in record construction\n    Use RecordWildCards to permit this\n    |\n125 |     return MetaPage { .. }\n    |            ^^^^^^^^^^^^^^^\n\nsrc/Lib/MetaPage.hs:127:66: error:\n    Not in scope: type constructor or class ‘Value’\n    |\n127 | checkDocrep1 :: Path Abs Dir -> Path Abs Dir -> Path Abs File -> Value -> ErrIO MetaPage\n    |                                                                  ^^^^^\ncabal: Failed to build ssg-0.0.4.2 (which is required by exe:ssgbake from\nssg-0.0.4.2).\n\n\n\n",
    "source": "cradle",
    "startLineNumber": 1,
    "startColumn": 1,
    "endLineNumber": 2,
    "endColumn": 1
}

The message 'failed ..' persists even after the code compile ok. It disappeared after I run the executable.

If this is more than a fluke I can probably give more information and try to reproduce.

jneira commented 3 years ago

Hi, thanks for the bug report and agree the error message could be improved. However cabal can fail for several different reasons (and not always its error messages are too good)

I expect a reasonable error message

It would be helpful to know some approximation to the message you would expect.

andrewufrank commented 3 years ago

Perhaps something

indicating that there was an error produced by compiling the module
analysis failed and therefore the full output from the compiler is given if it need be compacted to one line: Compilation of XX failed, but analysis of error not successful.

When HLS works, it is really helpful.

fendor commented 3 years ago

I think it would be a general improvement showing the error message produced by CradleLoadResult as it at least contains the command that failed and users could just execute it themselves for seeing the original error.

jneira commented 3 years ago

yeah, we could even add the suggestion, with the cli invocation if possible

andrewufrank commented 3 years ago

Perhaps something along the lines:

indicating that there was an error produced by compiling the module
analysis failed and therefore the full output from the compiler is given if it need be compacted to one line: Compilation of XX failed, but analysis of error not successful.

Including the CradleLoadResult might be helpful for users to understand somewhat more what goes on behind the scence.

When HLS works, it is really helpful.

andrewufrank commented 3 years ago

I see the error failed to parse... now with some regularity whenever I move files from a subdir in src (i.e. moving from one library to another one) or change the filenames. Details of the error message seem to include the 'old' names, which I take as indication that some cache is not updated/invalidated in such cases. Hope this help!

andrewufrank commented 3 years ago

I could only get rid of the error message with restarting the vscode - I would guess that vscode keeps somewhere inodes (which are still valid after moving a file or deleting=moving to trash).

Profpatsch commented 3 years ago

I got the same problem, the error message is scary even if it only means “local library depndency target didn’t compile”.

It will happen during normal development, basically any time you open Main.hs while you changed something in the Lib.hs and it doesn’t yet compile.

It will also stay around indefinitely, even after fixing Lib.hs errors.

haskell / haskell-language-server