Using procedural macros in core_arch

[lu-zero]

I'm getting back to implement the altivec support and probably I could cut a LOT of boilerplate by using something similar to paste or interpolate_name.

Since core_arch would end up being part of libcore I wonder if there are constraints in doing this.

Simply adding it as dependency in libcore shows a problem in proc-macro-hack, so probably it isn't that straightforward and would make the build process more brittle...

[lu-zero]

error[E0658]: non-ident macro paths are experimental (see issue #35896)
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro-hack-0.5.5/src/lib.rs:268:5
    |
268 |     syn::custom_keyword!(support_nested);
    |     ^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(use_extern_macros)] to the crate attributes to enable

error: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
error: Could not compile `proc-macro-hack`.

For reference :) (@dtolnay do you have any idea why it is happening?)

[dtolnay]

Macro paths were stabilized in rustc 1.30.0. Libcore compiles against nightly Rust so that would not be a problem.

[gnzlbg]

So is using a proc macro in libcore ok? (cc @alexcrichton ) AFAICT, unless the proc macro is no_core (which can't happen because of TokenStream), that would introduce a cyclic dependency (libcore -> proc_macro -> libcore).

[alexcrichton]

My gut instinct is that it doesn't work, but that's largely because rustbuild was never designed to work that way and I don't think core/std uses proc macros today yet. I would recommend in doing so to get rustbuild working before landing anything in stdsimd.

[lu-zero]

I tested with the current tree (after cleaning up some stale subrepos) and paste complains it cannot find core.

[gnzlbg]

So that makes sense to me because core has not been built yet. You might want to try only using paste as part of the stage1 and upwards, and see if you can make them pick core from the previous stage.

Do you need paste in core_arch, or only in the core_arch tests? (if its only the tests, then you might be able to use paste as a dev dependency, because the tests are built after core is built).

[lu-zero]

I'd use it in both places if possible. Crafting all the variants gets quite time intensive otherwise.

[lu-zero]

I ended up preparing some traditional macros in #752.

(also could we add a zulip room for stdsimd discussions)