cc @Shourya742 seems like if we try to connect to a proc-macro server that does not support postcard we will just hang on it now crashing as expected, we'll need to figure out a different approach here.

cc @Shourya742 seems like if we try to connect to a proc-macro server that does not support postcard we will just hang on it now crashing as expected, we'll need to figure out a different approach here.

I guess I know the reason for this, the json framing uses read_line, which blocks until it sees a newline. That means if the server doesn’t send one, we end up stuck waiting indefinitely. The problematic bit is here:

fn read<'a, R: BufRead>(
    inp: &mut R,
    buf: &'a mut String,
) -> io::Result<Option<&'a mut String>> {
    loop {
        buf.clear();
        inp.read_line(buf)?;
        buf.pop(); // Remove trailing '\n'

When we intialize the client with postcard, we don't write new line as the delimitor. I’ll send a patch.

So looking at things, the --format flag does seem to validate its inputs on the latest nightly, so we might just want to hold off a bit. Do a toolchain version check and then retry things here. The postcard protocol not using lineendings seems fine to me after all

So looking at things, the --format flag does seem to validate its inputs on the latest nightly, so we might just want to hold off a bit. Do a toolchain version check and then retry things here. The postcard protocol not using lineendings seems fine to me after all

I was thinking that if we don’t receive a response within a specified time, we should abort the process and fall back.

that would work too and is definitely something we should implement.

I'll revert some parts here for now to unblock the pre-releases. And I'll also include #21132. It was a mistake not naming both of these flags legacy i think since we do want to replace the protocol entirely at some point.