taiki-e
Other proc macros that change output non-deterministically can bypass soundness checks
It's been discovered that pin_project_lite is unsound when the macro is applied to type definitions that contain misbehaving proc macros. There is ongoing discussion on how the rust language could possibly be changed to avoid this problem, as other crates (such as bytemuck and zerocopy) are also affected.
The pin_project_lite crate is notable for being a macro_rules!, as opposed to a derive macro as found in other cases. As such, I've filed this issue for awareness. See https://github.com/rust-lang/rust/issues/148793#issuecomment-3530738268 and https://github.com/rust-lang/rust/issues/148423#issuecomment-3530744463 for details.
First, I believe deterministically returning outputs that behave differently from inputs is an intended behavior of macros, and I think the discussion that that resistance to it may be necessary, is valid. (e.g., https://github.com/taiki-e/pin-project/issues/32, https://github.com/taiki-e/pin-project/issues/342)
However, I believe non-deterministically returning outputs that behave differently from inputs is fundamentally useless because users cannot trust the behavior of macro outputs.
Personally, I treat macros like the latter as malicious macros or macros that may not be malicious but have serious bugs and should not be used. (I also treat macros created by users to abuse specific APIs as a kind of malicious macros.)
I don't think considering resistance to malicious macros is completely useless (e.g., I've implemented a mitigation for a kind of malicious crate in the past: taiki-e/pin-project#336), but as I said in that PR, malicious crates can do anything, and user code is never in a safe state when it depends on them even if resistance exists. Therefore, I tend not to view the lack of resistance against them as an actual bug.
