I'll report a bug if I can isolate it, but just in case, is anyone else seeing errors in proc-macros as of the latest release? I'm getting
proc-macro panicked: use-after-free in `proc_macro` handle and
proc-macro panicked: internal error: entered unreachable code, for my own proc macros (whose implementation has not changed in a while, although I suspect that on earlier versions of r-a they just weren't being run).
It's an (or a series of) ABI changes in nightly
You can try downgrading to a nightly from before May 10th or so, or use stable
I see references to that on the issue, is this a bug in the nightly ABI or a change that requires recompiling everything to use the same updated ABI?
We don't want to reuse the
rustc implementation (even if it were possible, I don't know), so we ship a copy of the code that runs on the proc macro side with some appropriate shims on the RA
If the ABI changes, we need to update our bundled code, and to update our shims in RA to support anything new that's in there
We don't want to reuse the
rustcimplementation (even if it were possible, I don't know)
rustc implementation is only accessible behind a feature flag.
But we can't support both the stable and the nightly ABI at once
There's https://github.com/rust-analyzer/rust-analyzer/pull/9047, but it might need more changes
oh wow, ABI changes sound really painful. I guess this happens on every change and persists for 12 weeks
is it possible to detect that you are running on nightly?
Yeah, but it's not implemented
hmm don't we already read the proc macro ABI version or something like that?
Yeah, but only to check the
rustc version against our
We don't figure "oh, it's a nightly and we know these to be broken, so let's disable proc macros for now"
wait. the proc macro abi is “versionised”? or are we talking about comparing rustc versions?
having some kind of proc macro abi versioning would be nice
we look at the rustc version stored in the proc macro's dylib
The ABI itself is not versioned
And we don't support multiple versions of it, though that would be nice
I think the ideal solution would be to ship the required code as part of the rustup toolchain, that way it auto-updates and is always compatible with the compiler in use
The problem with that is that every time the proc macro abi changes, the api that needs to be implemented by rust-analyzer changes too.
Yeah, like in https://github.com/rust-analyzer/rust-analyzer/issues/9049 and https://github.com/rust-analyzer/rust-analyzer/pull/9047/files#diff-33c902ac596e0d7ed8a6c15d046920d3cdb70bcabab1461c8bb46a294a97cf3cR524-R526
If we compile that code ourselves, that means we'll get notified when ABI breakage happens, so that seems strictly better than the current state
Maybe I should finally look into WASM and whether it can make this easy, then rustup could just include a WASM blob we could use without compiling anything
would it even be possible for us to support different versions of the ABI in the same binary (since the proc-macro bridge is the same rust-analyzer binary as everything else)?
I think the bridge doesn't export any
#[no_mangle] functions directly to the proc macro, but instead passes a function pointer to the proc macro.
This means that it should be possible to support different proc macro bridge versions in the same executable I think.