Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1.30 beta] Macros recursion limit detection changed #54464

Closed
pietroalbini opened this issue Sep 22, 2018 · 8 comments
Closed

[1.30 beta] Macros recursion limit detection changed #54464

pietroalbini opened this issue Sep 22, 2018 · 8 comments

Comments

@pietroalbini
Copy link
Member

@pietroalbini pietroalbini commented Sep 22, 2018

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.

@petrochenkov

This comment has been minimized.

Copy link
Contributor

@petrochenkov petrochenkov commented Sep 22, 2018

Oh god.

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

@petrochenkov

This comment has been minimized.

Copy link
Contributor

@petrochenkov petrochenkov commented Sep 22, 2018

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

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

@nikomatsakis nikomatsakis commented 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

This comment has been minimized.

Copy link
Member

@pnkfelix pnkfelix commented 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 pnkfelix removed the I-nominated label Sep 27, 2018
@pnkfelix

This comment has been minimized.

Copy link
Member

@pnkfelix pnkfelix commented Sep 27, 2018

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

@pietroalbini

This comment has been minimized.

Copy link
Member Author

@pietroalbini pietroalbini commented Sep 28, 2018

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

@petrochenkov

This comment has been minimized.

Copy link
Contributor

@petrochenkov petrochenkov commented Sep 28, 2018

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

This comment has been minimized.

Copy link
Member

@pnkfelix pnkfelix commented Oct 4, 2018

closing as wontfix.

@pnkfelix pnkfelix closed this Oct 4, 2018
@pietroalbini pietroalbini moved this from Triaged to Won't fix in 1.30 regressions Oct 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
1.30 regressions
  
Won't fix
4 participants
You can’t perform that action at this time.