rust-analyzer --stage=1 mixes incompatible proc_macro server and client

[m-ou-se]

Looks like rust-analyzer built with --stage=1 will use the proc_macro server from the checkout, but the proc_macro client from beta (stage 0). This "works" "fine" as long as we don't make any changes to the proc macro bridge. But it breaks terribly when we make any changes to the proc_macro interface.

To reproduce:

Make some backwards-incomplatible change to the proc macro bridge communication protocol. For example, in library/proc_macro/src/bridge/rpc.rs:

@@ -115,13 +115,14 @@ fn decode(_: &mut Reader<'_>, _: &mut S) -> Self {}
 impl<S> Encode<S> for u8 {
     fn encode(self, w: &mut Writer, _: &mut S) {
         w.push(self);
+        w.push(0);
     }
 }

 impl<S> DecodeMut<'_, '_, S> for u8 {
     fn decode(r: &mut Reader<'_>, _: &mut S) -> Self {
         let x = r[0];
-        *r = &r[1..];
+        *r = &r[2..];
         x
     }
 }

And then run

./x.py test src/tools/rust-analyzer --stage=1

Everything panics.

(With --stage=2, it works fine.)

This is a problem, because we run the r-a tests at --stage=1 as part of CI. This means we currently cannot make any changes to the proc macro bridge (without purposely breaking and disabling tests).

Discovered while trying to merge #139671

[m-ou-se]

cc @rust-lang/rust-analyzer

[m-ou-se]

Perhaps we should include the compiler version or something similar in the proc macro bridge communication protocol. Then we would have detected this much earlier.

[Veykril]

Stage 1 and stage 2 have the same rustc version string I assume right? Which means our version check won't catch it when we load a proc-macro dylib.

Sounds like --stage 1 r-a generally is not usable with proc-macros, so it sounds reasonable to me to not have --stage 1 tested / or specifically not have proc-macro server tests in r-a run in stage 1.