tailhook/quick-error

error processing large numbers of items

Opened this issue · 5 comments

cmsd2 commented
<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.

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.

@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. :-)

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...

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

cmsd2 commented

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