Introduce ra_proc_macro_srv

[edwin0cheng]

This PR add preliminary for server side of proc macro :

1. Add crate setup
2. IO for server side

[edwin0cheng]

@matklad We need mbe here for parsing string to ra_tt::Token which is used for lib_proc_macro bridge api.

[edwin0cheng]

CI failed in deny_c for libloading crate. Um...

[Veetaha]

Maybe use dlopen() and LoadLibrary() directly?

[bjorn3]

The C code is used for a lock around dlerror. This was necessary to fix nagisa/rust_libloading#32. It can't be written in C, as it uses a weak global variable to store the lock in. (rust-lang/rust#29603) This way multiple versions of libloading can use the same lock without conflicts.

https://github.com/nagisa/rust_libloading/blob/953681d3958c04d735b30a1170b3fa6fc8ed7ab0/src/os/unix/global_static.c

#include <pthread.h>
#include <stdlib.h>

pthread_mutex_t __attribute__((weak)) rust_libloading_dlerror_mutex = PTHREAD_MUTEX_INITIALIZER;

void __attribute__((weak))
rust_libloading_dlerror_mutex_lock(void)
{
    if (pthread_mutex_lock(&rust_libloading_dlerror_mutex) != 0) {
        abort();
    }
}

void __attribute__((weak))
rust_libloading_dlerror_mutex_unlock(void)
{
    if (pthread_mutex_unlock(&rust_libloading_dlerror_mutex) != 0) {
        abort();
    }
}

[edwin0cheng]

Another reason : We would need to get proc-macro symbols from these dylibs in different platform (linux, mac, windows). and using libloading to handle them fairly easily.

[matklad]

Maybe use dlopen() and LoadLibrary() directly?

This is exactly the case where depending on 3d-party lib can save us a royal amount of pain :)

[bjorn3]

Maybe deny_c can become a script that checks if it's parent process is the build script for libloading and only execute the c compiler in that case?

[flodiebold]

Maybe we should have a cargo feature for enabling/disabling proc macro support, and could then do the deny_c check without that?

[edwin0cheng]

Maybe we should have a cargo feature for enabling/disabling proc macro support, and could then do the deny_c check without that?

That deny_c check is defined in environment variable, so we would have to separate two CI check action to support it. Anyway, we have to change our CI for the proc-macro-srv executable to be included in the release package.

[matklad]

I'm ok with just disabling deny_c check. I've also opened an upstream issue about making the c dep optional (which I think it doable).

…

On Wed, 1 Apr 2020 at 13:02, Edwin Cheng ***@***.***> wrote: Maybe we should have a cargo feature for enabling/disabling proc macro support, and could then do the deny_c check without that? That deny_c check is defined in environment variable, so we would have to separate two CL check action to support it. Anyway, we have to change our CI for the proc-macro-srv executable to be included in the release package. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3800 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANB3M56RVFG2Z4KS4QBS7TRKMNMJANCNFSM4LYOABKA> .

[matklad]

bors r+

[bors]

Build succeeded

• Rust (windows-latest)
• Rust (macos-latest)
• TypeScript
• Rust (ubuntu-latest)