I don't know if this has been requested by others, but I personally want procedure macros to have an idea of what target architecture the user code is being compiled for, so that I can generate some platform-specific code for the user (for performance reasons).
This behavior could be achieved by adding a bunch of
#[cfg(...)] conditions in the generated code, but that's inefficient and the complexity of the
cfg expression grows exponentially as I consider more architectures, and therefore far from ideal.
I think it make sense to allow procedure macro having access to, during user code compilation, some common information including:
- target type (binary/library/example/doc/etc.)
- target architecture (x86, x64, etc.)
- optimization level (debug/release)
Since a procedure macro behaves like a compiler plugin, I haven't seen any reason a procedure macro shouldn't be allowed for this. If this ability can be supported, then the power of procedure macros in my opinion could be pushed even further.
In terms of how to support it, I guess provide some kind of environment variable to the procedure macro (only during user code compilation) could be feasible?