[1.30 beta] Macros recursion limit detection changed

[emilyalbini]

In the 1.30 beta the counter of macro recursions is increased by one compared to the 1.29 stable release. This causes build failures for crates with a macro with exactly 64 recursions.

• polish_notation 0.1.0 regressed from stable to beta (build log) cc @firba1

[petrochenkov]

Oh god.

This most likely happens due to #[test] being (correctly) counted as a macro expansion (#53410).

[petrochenkov]

This turns out to be a known regression #53410 (comment), so I assume wontfix.

[nikomatsakis]

I'd probably be ok with calling this a WONTFIX for now, though I'd like to think about possible ways to "future proof" things like the recursion depth better. It's worth pointing out that this particular regression won't affect consumers of the crate, right? Only its original author?

[pnkfelix]

discussed at T-compiler meeting. Team is generally leaning towards closing as WONTFIX.

We did discuss various work-arounds (e.g. increasing the limit by +1 or x2... and generalizations thereof, like applying that transform also to user-provided recursion limits).

But in general no one seemed too eager to actually deploy any such "fix", and its not clear whether a better solution is available.

So, if this is still open next week in the same state with no objections, we'll close as WONTFIX.

[pnkfelix]

(leaving priority unassigned since the priority is somewhat fuzzy, given our leaning towards WONTFIX)

[emilyalbini]

Maybe we could ignore macros expanded by the compiler in the recursion limit?

[petrochenkov]

Please no, this cure would be much worse than the disease.
Recursion limit is hit in polish_notation 0.1.0 in a test that's specifically testing recursion limit, it didn't happen accidentally.

[pnkfelix]

closing as wontfix.