4 ms·

> Rust does not have a textual substitution pre-processor Is that not pretty much what Rust's procedural macros are? [0] Except for the fact that they do not

> Rust does not have a textual substitution pre-processor Is that not pretty much what Rust's procedural macros are? [0] Except for the fact that they do not allow emitting invalid token streams (which is something you don't want anyways), it can do any arbitrary manipulation of source code, but in a way that is integrated with the compiler and less prone to breaking the program. [0] https://doc.rust-lang.org/reference/procedural-macros.html https://doc.rust-lang.org/reference/procedural-macros.html

qppo 6y ago
its splitting hairs but not really. Rust's proc macros need to be explicitly invoked using special syntax at the usage site, either by annotating a statement or enclosing a block of tokens. On top of that, they do token replacement (or addition, with derive macros) which means they can only take valid input tokens as an argument (compared to macro_rules which can take arbitrary strings). Textual substitution is less rigorous. It tells the compiler to replace a string with another, wherever it is seen. There's no restriction that it must be valid token input to be replaced or that it needs to be an explicit usage of the macro.
Arnavion 6y ago
A proc macro would still need to be invoked as either cpp_call! { fn foo() { ... } } or #[cpp_call] fn foo() { ... } The former can be written even with a macro_rules macro. Regardless, both macros have to work by parsing the whole input tokentree `fn foo ( ) { ... }` and emitting it back with an `unsafe` prepended. The macro invocation cannot expand to just `unsafe`.
- steveklabnik 6y ago
  Yes, this is what I was meaning, thank you.
ComputerGuru 6y ago
> Except for the fact that they do not allow emitting invalid token streams (which is something you don't want anyways) Reminds me of some of stringification abused in the Linux kernel. What looks like a function call passing the literal text param1## as an argument, where it would then trigger a different stringification in a subsequent preprocessor pass that prepended ##foo to the passed argument.

qppo 6y ago

its splitting hairs but not really. Rust's proc macros need to be explicitly invoked using special syntax at the usage site, either by annotating a statement or enclosing a block of tokens. On top of that, they do token replacement (or addition, with derive macros) which means they can only take valid input tokens as an argument (compared to macro_rules which can take arbitrary strings). Textual substitution is less rigorous. It tells the compiler to replace a string with another, wherever it is seen. There's no restriction that it must be valid token input to be replaced or that it needs to be an explicit usage of the macro.

Arnavion 6y ago

A proc macro would still need to be invoked as either cpp_call! { fn foo() { ... } } or #[cpp_call] fn foo() { ... } The former can be written even with a macro_rules macro. Regardless, both macros have to work by parsing the whole input tokentree `fn foo ( ) { ... }` and emitting it back with an `unsafe` prepended. The macro invocation cannot expand to just `unsafe`.

steveklabnik 6y ago
Yes, this is what I was meaning, thank you.

ComputerGuru 6y ago

> Except for the fact that they do not allow emitting invalid token streams (which is something you don't want anyways) Reminds me of some of stringification abused in the Linux kernel. What looks like a function call passing the literal text param1## as an argument, where it would then trigger a different stringification in a subsequent preprocessor pass that prepended ##foo to the passed argument.