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

error processing large numbers of items #22

Open
cmsd2 opened this issue Apr 21, 2016 · 5 comments
Open

error processing large numbers of items #22

cmsd2 opened this issue Apr 21, 2016 · 5 comments

Comments

@cmsd2
Copy link

cmsd2 commented Apr 21, 2016

<quick_error macros>:192:1: 197:60 error: recursion limit reached while expanding the macro `quick_error
<quick_error macros>:192 quick_error ! (
<quick_error macros>:193 ENUM_DEFINITION [ $ ( $ def ) * ] body [
<quick_error macros>:194 $ (
<quick_error macros>:195 $ ( # [ $ imeta ] ) * => $ iitem ( $ ( ( $ ( $ ttyp ) , + ) ) * ) {
<quick_error macros>:196 $ ( { $ ( $ svar : $ styp ) , * } ) * } ) * $ ( # [ $ qmeta ] ) * => $ qitem (
<quick_error macros>:197 ( $ ( $ qtyp ) , * ) ) {  } ] queue [ $ ( $ queue ) * ] ) ; } ; (
Could not compile `openid-connect`.

i have an error type with 17 possible error types. is that too many? it works if i delete one. doesn't seem to matter which one i get rid of.

@cmsd2 cmsd2 changed the title error processing large numbers items error processing large numbers of items Apr 21, 2016
@tailhook
Copy link
Owner

Almost certainly yes. We have discussed that there is a limit, but I've never reached it myself.

I may happen to be possible to refactor the macro to make the limit bigger, but probably I will not have any time for this soon.

@colin-kiegel
Copy link
Contributor

colin-kiegel commented Apr 21, 2016

@cmsd2 simplay add #![recursion_limit="100"] to your crate and increase the value as needed.

@tailhook a few 3-4 months ago I worked on a tail-call-optimization scheme for rust macros. This was the exact use case I had in mind. It uses higher-order-macros as callbacks + branching to amplify the recursion limit exponentially (roughly like ~ 2^N, where N is the real limit). I tested it thorough-fully. And guess what, the good news is "it works". :-) But there is also bad news: the rust compiler looses context-information about all input-tokens due to the higher-order-macro-callback trickery. Thus error messages get cryptic, when a token could not get matched. In these cases rust can not point you to the position in your code anymore, which causes the error. This is quite a high price to pay, I think. Increasing the recursion "manually" might be the better way.

However, if you are interested, you can have a look yourself at this proof-of-concept code, which recursively prints 26 characters with a recursion limit of only 7: https://github.com/colin-kiegel/enum-transform/blob/tailcall_optimization/src/tailcall_optimization.rs. Even if the drawbacks outweigh the benefits this is quite interesting stuff. :-)

@colin-kiegel
Copy link
Contributor

PS: After the great macro reform, this crate could be re-implemented as a procedural macro and all this pain should be gone. ;-)

So we are only talking about temporary workarounds here - even if temporary might be quite a while...

@tailhook
Copy link
Owner

Hm, if increasing recursion limit is enough I don't see any problem here. We just need to add it to the docs.

@cmsd2
Copy link
Author

cmsd2 commented Apr 21, 2016

crikey. i got more than i bargained for. Thanks for the workaround at least -- that fixes my problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants