Repository navigation
[1.30 beta] Macros recursion limit detection changed #54464
Description
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.0regressed from stable to beta (build log) cc @firba1
Activity
petrochenkov commentedon Sep 22, 2018
Oh god.
This most likely happens due to
#[test]being (correctly) counted as a macro expansion (#53410).petrochenkov commentedon Sep 22, 2018
This turns out to be a known regression #53410 (comment), so I assume wontfix.
nikomatsakis commentedon Sep 27, 2018
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 commentedon Sep 27, 2018
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 commentedon Sep 27, 2018
(leaving priority unassigned since the priority is somewhat fuzzy, given our leaning towards WONTFIX)
emilyalbini commentedon Sep 28, 2018
Maybe we could ignore macros expanded by the compiler in the recursion limit?
petrochenkov commentedon Sep 28, 2018
Please no, this cure would be much worse than the disease.
Recursion limit is hit in
polish_notation 0.1.0in a test that's specifically testing recursion limit, it didn't happen accidentally.pnkfelix commentedon Oct 4, 2018
closing as wontfix.