Weird method location shouldn't match unknown location #2244
Conversation
|
Hi @jcoleman thanks for the PR! Can you add a spec for this scenario? |
|
I’m certainly happy to try to add a test; I red-greened this in a live system hence why I don’t have one yet. |
jcoleman
force-pushed
the
patch-1
branch
2 times, most recently
from
dcc1f7f
to
45ae63e
Compare
|
@andrehjr I've added a test (for interest's sake: the naming in the test was mostly to match the source of finding this error, which was in a Capistrano 2 task). |
Methods that don't have a source location (e.g., C methods, or methods created via metaprogramming or even `alias_method` to C methods) are not reasonable possible matching methods for a "weird method" we need to locate. In this case `renamed_method_source_location` can also return `nil` if the actual code in question is a bare script (i.e., no methods). If that script is loaded via `eval` then we'll end up in the weird method path in the first place, but no method matching can be found, and if a no-source-location method exists, we'll return that. Down the line that's particularly painful because the source loading thinks it's a C method, but it can actually be from metaprogramming (and `alias_method`!), and then `Pry::Method#pry_doc_info` raises an error, and `wherami` breaks even though we already have valid `__FILE__` and `__LINE__` values.
|
@andrehjr Thanks for merging this! Anyway you'd be able to release a 0.14.2 soon so that I can easily install the fix on our systems? |
|
@andrehjr Bump on my question about whether you'd be able to release an updated version. |
|
@andrehjr Any chance you have a timeline for release a new minor revision? |
|
Soon, hopefully. I don't currently have a timeline(which depends on other maintainers), there's another important fix I want to work on first. |
Methods that don't have a source location (e.g., C methods, or methods
created via metaprogramming or even
alias_method) are not reasonablepossible matching methods for a "weird method" we need to locate.
In this case
renamed_method_source_locationcan also returnnilifthe actual code in question is a bare script (i.e., no methods). If that script
is loaded via
evalthen we'll end up in the weird method path in the firstplace, but no method matching can be found, and if a no-source-location
method exists, we'll return that.
Down the line that's particularly painful because the source loading thinks
it's a C method, but it can actually be from metaprogramming (and
alias_method!),and then
Pry::Method#pry_doc_inforaises an error, andwheramibreaks eventhough we already have valid
__FILE__and__LINE__values.