Proc macro errors can lead to rustc panics at stage1 or on non-Linux

[RalfJung]

Update (by @eddyb): this also occurs with x.py test --stage 1 src/test/ui on Linux (and is responsible for several // ignore-stage1 in src/test/ui), so I'm updating the title to reflect it.
See also #59998 (comment) for more details.

---

Discovered at #59769 (comment): running the ui\proc-macro\invalid-punct-ident-*.rs tests on some platforms (observed on Windows and macOS but not on Linux) leads to things like

thread 'rustc' panicked at 'unsupported character `'`'`', src\libsyntax_ext\proc_macro_server.rs:315:13
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

being printed on stderr.

Cc @eddyb

[RalfJung]

This seems to also happen on macOS. Just not on Linux. @eddyb speculated that this is about whether libstd is shared between the proc macro client and server. I do not know what that means.

[eddyb]

Statically linked Rust libraries (such as libcore or libstd) can be are duplicated between non-Rust "final" artifacts (e.g. binaries, or cdylibs, and the latter is what proc macros are).

That is, you can end up with several copies of libstd's functions and globals in one process, if you dynamically load a Rust cdylib / proc macro crate.
The functions aren't really an issue, but globals control panicking, and this means that a proc macro is not guaranteed to use the same panicking "global state machine" as the rustc that loaded it.

We account for this in terms of catching panics and transporting them over RPC, but we've forgotten to do the "stderr printing bypass" for panics happening on the server-side (i.e. caused by rustc handling a request from a proc macro client), we're only bypassing the printing for panics that happened client-side.

Also, to be clear, sharing libstd's is not the solution, but rather Linux is hiding an issue because it happens to do so (and this is not the case at e.g. stage1, because the server and client libstd's are incompatible).
#59769 (comment) has more info on what we might do to fix this.

[pnkfelix]

triage: P-medium. Leaving nomination tag in hopes we can discuss at meeting.

[pnkfelix]

discussed at T-compiler meeting. self-assigning. unnominating.

[eddyb]

Not sure yet if relevant, but: turns out my expectation of proc macros being "most cdylib" is wrong because (more details here: #99909 (comment)) of this bail-out:

rust/compiler/rustc_codegen_ssa/src/back/linker.rs

Lines 651 to 661 in 9067d52

	// We manually create a list of exported symbols to ensure we don't expose any more.
	// The object files have far more public symbols than we actually want to export,
	// so we hide them all here.
	if !self.sess.target.limit_rdylib_exports {
	return;
	}
	if crate_type == CrateType::ProcMacro {
	return;
	}

AFAICT that's what's causing proc macro dylibs to have so many dynamic exports (instead of exactly one, the proc_macro_decls or w/e it's called) - and if all it takes for the panic runtimes to conflict is dynamic linking to unify one of those symbols, that might be what's been causing all of these issues for years and we just didn't look in the right place...