Ok, maybe that claim is a tiny bit too strong, but I'll defend it anyways.
Consider that rust macros are allowed to have side effects and access outside resources, they aren't pure functions. I'd argue that any system that runs them repeatedly in an attempt to find a fixed point is either incorrect (backwards compatibility wise), or an all together new macro system that happens to run in parallel to the current one and call itself the same thing (debatable, I know). Nor can we simulate the proc macro and only let the side effects occur once we reach a fixed point, because the proc macros behavior can depend on the values returned by those external systems.
The halting problem is arguably not a theoretical issue, since the type system is already turing complete (up to arbitrary limits on recursion depth that could exist here to).
I too am pretty confident that there will be no generally type-aware Rust macro system, which is legitimately disappointing.
Still, the types of many named entities will typically be knowable. So, a macro system that can provisionally operate on types when they are known, or even that supports macros that require that the types of certain names be known, seems doable, in principle. It would need a good usage story to get any traction.
Consider that rust macros are allowed to have side effects and access outside resources, they aren't pure functions. I'd argue that any system that runs them repeatedly in an attempt to find a fixed point is either incorrect (backwards compatibility wise), or an all together new macro system that happens to run in parallel to the current one and call itself the same thing (debatable, I know). Nor can we simulate the proc macro and only let the side effects occur once we reach a fixed point, because the proc macros behavior can depend on the values returned by those external systems.
The halting problem is arguably not a theoretical issue, since the type system is already turing complete (up to arbitrary limits on recursion depth that could exist here to).