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

[andrewufrank]

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]

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]

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]

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]

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

[andrewufrank]

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]

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]

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]

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.