-
Notifications
You must be signed in to change notification settings - Fork 914
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Warnings emitted by requiring 'ostruct' #8200
Comments
Deactivate warnings test on JRuby due to jruby/jruby#8200
This is related to #7524 which added additional whitelisted methods for which we won't warn. The problem here is that JRuby wants to warn users when they alias "special" methods that access the caller's frame, since those aliases are often wrapped with another method that breaks that frame access. For example, you can't alias and wrap These two methods access the caller's frame in order to get the scope for refinement lookups. If called via a wrapper, they won't work properly, because they'll use the wrapper method's scope. The fix I proposed in #7524 whitelists these names so they won't be aliased, since we know that openstruct does this. In other cases we have worked with @marcandre to reduce the number of methods it aliases in this way, but neither solution is really very good. |
Further clarification of why we warn: In order to optimize method bodies by eliminating extra frame and scope information, we gather a list of all method names known to access the caller's frame or scope. When one of these methods gets aliased, that becomes a method name that also needs caller access, and any code already compiled to call that new name may not have the right context set up. So we warn to indicate these methods may not behave like the user expects. |
The ostruct library aliases all methods from Object/Kernel with a bang suffix ("!") to allow them to be callable even though the OpenStruct should support them as field names. Because we use record these names in a table of known frame-aware methods, we have typically warned when aliasing them. This rarely comes up, since aliasing usually is accompanied by wrapping, which breaks their behavior on all implementations, but this aliasing in ostruct is unusual and pervasive, leading to issues like jruby#8200. This patch assumes we're going to have issues with ostruct forever and eagerly adds the "!" names alongside the regular names for all method names that match /[a-z_]/, so taht existing methods and future methods will behavior properly and not warn when aliased. It adds a small amount to startup, since these method names must be added twice, but there are not many such names in the system. Fixes jruby#8200 Replaces jruby#7524
The ostruct library aliases all methods from Object/Kernel with a bang suffix ("!") to allow them to be callable even though the OpenStruct should support them as field names. Because we use record these names in a table of known frame-aware methods, we have typically warned when aliasing them. This rarely comes up, since aliasing usually is accompanied by wrapping, which breaks their behavior on all implementations, but this aliasing in ostruct is unusual and pervasive, leading to issues like jruby#8200. This patch assumes we're going to have issues with ostruct forever and eagerly adds the "!" names alongside the regular names for all method names that match /[a-z_]/, so taht existing methods and future methods will behavior properly and not warn when aliased. It adds a small amount to startup, since these method names must be added twice, but there are not many such names in the system. Fixes jruby#8200 Replaces jruby#7524
I pushed #8206 with a new sort of fix: eagerly add all frame-aware names with an additional bang-suffixed version in expectation that this will be an ongoing problem with ostruct. This could probably be reduced to just Kernel, Object, and BasicObject names but that is a messier fix. |
馃憢 Hello my friends! Long time no see, some might say the not seeing level is over 9000 ;)
Environment
Behaviour
Just requiring open struct yields the following warnings with warnings turned on
Expected Behavior
No warnings :)
More context
FWIW the simplecov CI is failing because of this, I'll work around it for now somehow. We have a test that just makes sure we don't emit warnings.
Cheers, and thanks for all your work 馃挌
The text was updated successfully, but these errors were encountered: