Some notes about the panic

[edwin0cheng]

Hi, I am studying the https://github.com/fedochet/rust-proc-macro-expander which is an awesome project. And see the issue in rust-lang/rust#60593.

After a little bit of digging, my guess is, it is not related to ABI compatible problem. It seem to be related to the different of thread_local storage of static linkage and dynamic linkage.

The actual panic is this line.
And state is actually a thread_local :

https://github.com/rust-lang/rust/blob/dc6db14e1cd60012f25be4fd8d2eb96ea5b4bb68/src/libproc_macro/bridge/client.rs#L269

On the other hand, in your example code :

rust-proc-macro-panic-inside-panic-expample/src/main.rs

Line 164 in 6ef3a64

let result = client.run(

client.run function will call Bridge::enter and set the state to BridgeState::Connected. Note that this is statically link to main crate.

And after that, when the actual TokenStream start to parse, Bridge::with will be called from shared library crate and it will trigger the panic.

It seem to be two thread local are different, such that the panic get raised. But I don't know enough about linux shared librrary and thread local mechanism to understand this bug.

[fedochet]

@edwin0cheng hi! Thanks for your interest in proc macro expander :)

I have thought about this possibility too (the fact that there are two independent thread local variables), but, unfortunately, it does not explain why there is no panic when procedural macros itself is compiled with one rust version, and code which links it dynamically is compiled with another

I do agree that it does not relate to ABI compatibility, and I am not sure whether it's a bug or very strange behavior (from my point of view) that is expected

Also, the approach I am using in proc macro expander is mocked from the compiler itself; however, the compiler does not run into this kind of problems for some reason

[edwin0cheng]

@fedochet It is so strange... For some reason i have to upgrade my Windows WSL from Ubuntu Xenial (16.04) to Bionic (18.04), and the bug is gone! And then i reinstall Xenial and confirm the bug still exists in there.

I start to strongly suspect it is related how dynamic linkage works and will try to investigate further.

[edwin0cheng]

Finally i found the actual reason of the bug.

I can confirmed that the thread_local i mentioned previously are different in Bridge::enter and Bridge::with (by inserting dbg! in rustc source code directly). And it is because Bridge::with use a wrong thread local coming from static linkage.

Why the static linkage is introduced ? Surprisingly it is introduced by syn crate we used to parse the input string to TokenStream. Seem like dynamic linker is "smart" enough to merge some code path from dynamic linkage to static linkage. And that's why it depends on how dynamic linker implementation.

Also, the approach I am using in proc macro expander is mocked from the compiler itself; however, the compiler does not run into this kind of problems for some reason

It is because in rustc they don't use procmacro::TokenStream, they use syntax::TokenStream :

https://github.com/rust-lang/rust/blob/9ebf47851a357faa4cd97f4b1dc7835f6376e639/src/libsyntax_ext/proc_macro_impl.rs#L17

use syntax::tokenstream::TokenStream;

// ....

impl base::AttrProcMacro for AttrProcMacro {
    fn expand<'cx>(&self,
                   ecx: &'cx mut ExtCtxt<'_>,
                   span: Span,
                   annotation: TokenStream,
                   annotated: TokenStream)
                   -> TokenStream {
        let server = proc_macro_server::Rustc::new(ecx);
        match self.client.run(&EXEC_STRATEGY, server, annotation, annotated) {
    // ....
}

So that's why in server.rs, it use a Server trait :

impl client::Client<fn(crate::TokenStream) -> crate::TokenStream> {
pub fn run<S: Server>(

So they don't introduce the static linkage of thread_local in their code.

[edwin0cheng]

it does not explain why there is no panic when procedural macros itself is compiled with one rust version, and code which links it dynamically is compiled with another

It also explains why there is no panic in here. Since if the version of static linkage are different from dynamically one, the dynamic linker will not try to merge its code path. So that both bridge::enter and bridge::with will use the same version of code. And that's why no panic occurred.

[fedochet]

@edwin0cheng that's a nice investigation, thanks a lot! I hope that, if you're right, there's something that could be done about it to prevent such kind of linkage issues, so expander could use macros compiled with the same version of rustc. Let's see what Eddyb would say about your theory

[edwin0cheng]

Seem like we can solve this problem by adding a flag RTLD_DEEPBIND when loading the dynamic library:

More info:
https://stackoverflow.com/questions/34073051/when-we-are-supposed-to-use-rtld-deepbind

[fedochet]

@edwin0cheng I've tried to use RTLD_DEEPBIND and it indeed worked! Thanks again for your investigation on this question 👍

[edwin0cheng]

You are welcome :) Since I am planing to use rust-proc-macro-expander in other project but this bug really block that usage.

However, note that RTLD_DEEPBIND only works in linux and mac. FreeBSD / OpenBSD do not support it. If your use case included these two platform, maybe you would consider to use another parsing method instead of syn crate.