Restrict the processes that can write to standard output when using stdio transport

[jfacorro]

Describe the bug
There are some external dependencies that are sometimes writing to stdout to report warning or errors. If the server is communicating through stdio the intervention of these dependencies corrupt the messages and some clients start failing completely.

To Reproduce
Create a module foo that has a duplicated type spec like the following:

-module(foo).
-export([baz/0]).
-type bar() :: atom().
-type bar() :: atom().

-spec baz() -> bar().
baz() -> ok.

Call foo:baz() from some other module and hover over the function call.

In VS Code this will cause the client to stop being able to process any response from the server. Opening the deveoper tools (i.e. Cmd+Shift+P -> Developer: Toogle Developer Tools) will show one or more instances of the following error: Error: Header must provide a Content-Length property..

In Emacs this isn't failing, I suspect it's because the client is more forgiving and is somehow able to recover from the cocrrupted messages.

Expected behavior
Nothing other that els_stdio should be able to write to standard output.

Actual behavior
Some clients (e.g. VS Code) stop working when something else writes to standard output.

Context

• erlang_ls version (tag/sha): 0.1.0-49-g134838a
• Editor used: VS Code 1.42.0
• LSP client used: Erlang LS 0.0.9

[jfacorro]

Some useful information on group leaders.

[robertoaloi]

@jfacorro Really nice finding, indeed! I had a similar issue with Elvis (see #444). This could also be related to the issue some Sublime users have experienced.

[robertoaloi]

Also, out of curiosity, which dependency was the offender in this case?

[jfacorro]

edoc which is used by the hover provider, is printing warnings to standard output through the usage of the edoc_report module.

[maxno-kivra]

I wonder if you could implement your own edoc reporter and get the warnings in a good way?