Rls: RLS hangs when you print in a procedural attribute macro

[Zinfour]

src/lib.rs

extern crate proc_macro;
use proc_macro::TokenStream;

#[proc_macro_attribute]
pub fn my_attribute_macro(attr: TokenStream, input: TokenStream) -> TokenStream {
    println!("print");
    input
}

tests/lib.rs

extern crate my_crate;
use my_crate::my_attribute_macro;

#[my_attribute_macro]
fn func() {}

When I open this project in vscode rls gets stuck in a loop, while if I add the println! after startup or if I use eprintln! instead it does not.

[alexheretic]

We're going to see this more I think. Compile time prints break rls-client comms because the language server protocol from rls is conducted on stdout. vscode-jsonrpc library cannot recover from dodgy stdout messages.

Any rls-side code that prints to stdout is a problem. We had similar problems before with rustc printing in certain cases. With procedural macros it looks like we open up a new way to do this.

eprintln! is the workaround as it won't interfere with stdout.

I was wondering since the last time whether we should really shore up rls to this problem once and for all. We could start rls with a wrapper process that has a dedicated channel for LSP messages and discards all stdout, or redirects stdout to stderr. The wrapper process talks to rls using the dedicated channel and prints the messages over it's own stdout without interference.

This way rustc, racer, other libs & proc-macros can go to town on stdout without breaking LSP.