4 ms·

This was a great learning resource for macros in the early days of Rust when there was almost no official documentation. Nowadays anything that's a bit more co

This was a great learning resource for macros in the early days of Rust when there was almost no official documentation. Nowadays anything that's a bit more complex should almost certainly use proc macros instead, which allow much saner implementations than complex, recursive macro shenanigans.

pitaj 5y ago
Absolutely disagree. If it can be done, without sacrificing useability, without proc macros, that's the way it should be done. Proc macros don't play well with IDEs, add compilation time, introduce dependencies, and can be a security risk. There are things that can be done to improve proc macros, like executing them in a WASM runtime, but currently they should only be used when necessary.
tialaramex 5y ago
On the other hand, procedural macros are the big guns and as such if you aim them wrong you are going to blow both feet off. A declarative macro is only at worst going to spew nonsense into your post-processed source where it was used - which the Rust tools are quite happy to show you - but a sufficiently bad proc macro could cause unlimited mayhem with no diagnostics available. I don't know if somebody is collecting the worst mistakes they've seen with proc macros, but m-ou-se's nightly-crimes! shows what sort of insanity is possible. [ https://github.com/m-ou-se/nightly-crimes https://github.com/m-ou-se/nightly-crimes nightly-crimes! blows away your compiler, running it again in a new environment where it will allow nightly features even though you've got a stable compiler installed... ]
- akiselev 5y ago
  > [ https://github.com/m-ou-se/nightly-crimes https://github.com/m-ou-se/nightly-crimes nightly-crimes! blows away your compiler, running it again in a new environment where it will allow nightly features even though you've got a stable compiler installed... ] That macros have access to the entire language including arbitrary IO is the defining feature of proc macros (not without controversy). The insanity here is the Rust compiler team adding the `RUSTC_BOOTSTRAP` env var which is a hack used to bootstrap rustc using a stable compiler despite the nightly features used by the codebase. All nightly-crimes does is use `std::process::Command` to rerun the compiler with the variable set [1], which tells rustc to throw all concepts of stability out the window. I haven't been following developments but one of the ideas (even has a PoC iirc) was to distribute and run proc macros as web assembly to improve build times and prevent such shenanigans. [1] https://github.com/m-ou-se/nightly-crimes/blob/main/yolo-rustc-bootstrap/src/lib.rs#L34 https://github.com/m-ou-se/nightly-crimes/blob/main/yolo-rus...
  - tialaramex 5y ago
    I don't see RUSTC_BOOTSTRAP as "insanity". Mara could do whatever here. Even if Rust's stable compilers had an internal parameter totally disabling nightly features, Mara's macro could take your compiler apart, identify the parameter, flip it, and re-assemble the compiler then run that. Indeed even if nightly was abolished, and new versions of the compiler simply didn't have these features, Mara's macro could go to github, download the old compiler that did have these features, install and run that. night_crimes! must be possible unless/ until sandboxing is implementing for proc macros and so the insanity is the same regardless of how it's possible. Which is fine, but like I said, these are big guns, not good to use just because they're tidier than a couple of declarative macros to get your job done.

pitaj 5y ago

Absolutely disagree. If it can be done, without sacrificing useability, without proc macros, that's the way it should be done. Proc macros don't play well with IDEs, add compilation time, introduce dependencies, and can be a security risk. There are things that can be done to improve proc macros, like executing them in a WASM runtime, but currently they should only be used when necessary.

tialaramex 5y ago

On the other hand, procedural macros are the big guns and as such if you aim them wrong you are going to blow both feet off. A declarative macro is only at worst going to spew nonsense into your post-processed source where it was used - which the Rust tools are quite happy to show you - but a sufficiently bad proc macro could cause unlimited mayhem with no diagnostics available. I don't know if somebody is collecting the worst mistakes they've seen with proc macros, but m-ou-se's nightly-crimes! shows what sort of insanity is possible. [ https://github.com/m-ou-se/nightly-crimes https://github.com/m-ou-se/nightly-crimes nightly-crimes! blows away your compiler, running it again in a new environment where it will allow nightly features even though you've got a stable compiler installed... ]

akiselev 5y ago
> [ https://github.com/m-ou-se/nightly-crimes https://github.com/m-ou-se/nightly-crimes nightly-crimes! blows away your compiler, running it again in a new environment where it will allow nightly features even though you've got a stable compiler installed... ] That macros have access to the entire language including arbitrary IO is the defining feature of proc macros (not without controversy). The insanity here is the Rust compiler team adding the `RUSTC_BOOTSTRAP` env var which is a hack used to bootstrap rustc using a stable compiler despite the nightly features used by the codebase. All nightly-crimes does is use `std::process::Command` to rerun the compiler with the variable set [1], which tells rustc to throw all concepts of stability out the window. I haven't been following developments but one of the ideas (even has a PoC iirc) was to distribute and run proc macros as web assembly to improve build times and prevent such shenanigans. [1] https://github.com/m-ou-se/nightly-crimes/blob/main/yolo-rustc-bootstrap/src/lib.rs#L34 https://github.com/m-ou-se/nightly-crimes/blob/main/yolo-rus...
- tialaramex 5y ago
  I don't see RUSTC_BOOTSTRAP as "insanity". Mara could do whatever here. Even if Rust's stable compilers had an internal parameter totally disabling nightly features, Mara's macro could take your compiler apart, identify the parameter, flip it, and re-assemble the compiler then run that. Indeed even if nightly was abolished, and new versions of the compiler simply didn't have these features, Mara's macro could go to github, download the old compiler that did have these features, install and run that. night_crimes! must be possible unless/ until sandboxing is implementing for proc macros and so the insanity is the same regardless of how it's possible. Which is fine, but like I said, these are big guns, not good to use just because they're tidier than a couple of declarative macros to get your job done.