detect errors in generated function declarations early #18605
Conversation
this would have detected #18577 before it was merged
| @@ -156,7 +156,7 @@ end | |||
| @generated function _g_f_with_inner(x) | |||
| :(y->y) | |||
| end | |||
| @test (_g_f_with_inner(1))(8) == 8 | |||
| @test_throws ErrorException _g_f_with_inner(1) | |||
|
|
|||
There was a problem hiding this comment.
added by @JeffBezanson in b43c5e0 - presumably this was needed for something?
I hate to backport new restrictions, even if it's just an earlier error on code that may be invalid. Will have to see how many packages are actually doing this. What's allowed in generated functions is starting to become a pretty restrictive subset of the language, and I don't think people have been aware of that or writing them that way.
There was a problem hiding this comment.
At some point, we likely may want to reintroduce this, but right now it gets handled incorrectly by the runtime system and will likely require not-backportable changes to fix.
What's allowed in generated functions is starting to become a pretty restrictive subset of the language
It's not "starting to become" because it's really not a new restriction, it's just better at enforcing correctness up-front now. On the other hand, the fix for #265 will add significant new restrictions to them, although it shouldn't affect anyone who's been fully observant of their definition.
and I don't think people have been aware of that or writing them that way.
That's too bad, but the manual does repeat several times that "you should /never/ write a generated function with side effects" [emphasis original] http:https://docs.julialang.org/en/latest/manual/metaprogramming/#generated-functions (unfortunately interspersed with various buggy examples). I can repeat it a few more times, but I consider it better just to enforce the restrictions.
There was a problem hiding this comment.
can we please fix and elaborate on the docs while we're at it then? Most people likely don't think of using closures or comprehensions as having side effects in this way.
There was a problem hiding this comment.
mixed into the same PR or on its own?
There was a problem hiding this comment.
either, as long as it gets done promptly. considering this is newly enforced, it should probably be documented here though.
There was a problem hiding this comment.
Yes, it's not reasonable to consider a generated function with a closure to have side effects --- the side effects there are in our implementation, not in the user's code.
For backporting, it doesn't matter how "new restriction" is defined. All that matters is whether code can break.
There was a problem hiding this comment.
Yes, I wouldn't have made this an error if that code wasn't already broken, so that this was just adding a clearer error than "segfault", corruption of precompiled files, or other errors in which method gets called.
I look forward to having anonymous functions again, so that they are uniquely defined by content rather than by name.
|
make it its own pr now? |
|
this isn't going into a release until the docs get updated for it as well, so you still need to do that - separately from the #265 fix, please |
|
Though if it breaks working user code it's not getting backported at all, so that will need to be tested. |
|
Just to reiterate, the user code would have worked on v0.4 (because we couldn't infer it), but is broken on v0.5 (because we can). This adds an explicit error message for the broken case, since the failure happens in rather unexpected circumstances and the symptoms are not straightforward. |
this would have detected #18577 before it was merged