-
Notifications
You must be signed in to change notification settings - Fork 177
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
Support module_function
in the indexer
#2653
Comments
Hi team, I am taking a look at this issue and will push something a few days later. |
Hello! Sounds good, I have assigned the issue to you. If you hit any blockers or have any doubts, please do not hesitate to ask for assistance here and the team can discuss the implementation. |
Hi @vinistock, Thank you for pointing out where the method entry should proceed. It's really helpful for me to start looking around the issue 😊. For the second requirement, I am confused about what you mean by "the same method." Do you mean Also, I would like to double-check with you for the first requirement. I think the fix is to add a new entry point, module_function, to the |
You're on the right track, but it's slightly different. When the indexing process finds the For example module Foo
# We process this method declaration and add an `Entry::Method` for it
def something; end
# After adding it to the index, then we find the method call to `module_function`
module_function :something
end So we need to operate on the entry that we just inserted. Here's the pseudo code of how this should happen case message
# ...
when :module_function
# get the argument for module function from the node, which is the name of the method we are
# turning into a module function
# then find the existing entry for the method. It will be something like
entries = @index.resolve_method(name_of_method, owner_name)
entries.each do |e|
# then turn the existing entries into private (this API may not exist yet)
e.visibility = Entry::Visibility::PRIVATE
# and add the singleton version of the method to the index (which is what module_function does)
# here the important part is that this method's owner will not be the same owner, but the
# singleton version of it
singleton_owner = @index.existing_or_new_singleton_class(name_of_owner)
new_entry = Entry::Method.new(..., singleton_owner)
end
end |
@vinistock, thanks for the pseudo code. I am now writing a test, but I need to figure out how to test the singleton entry. Right now, the following code is a piece of tests placed in method_test.rb. def test_visibility_tracking_with_module_function
index(<<~RUBY)
module Foo
def foo; end
module_function :foo
end
class Bar
include Foo
end
Bar.new.foo
RUBY
assert_entry("foo", Entry::Method, "/fake/path/foo.rb:1-2:1-14", visibility: Entry::Visibility::PRIVATE)
# How can I make another assertion to test Bar.new.foo?
end |
You need to get a handle for the entry so that you can assert that the owner is correct (example). When you get the entries for
|
Hi @vinistock, thank you! I think I am ready to push code for reviews, but I got permission denied 😅 |
You need to fork the repository in order to propose PRs in open source repositories you don't have permissions. This guide explains it in more detail https://docs.github.com/en/get-started/exploring-projects-on-github/contributing-to-a-project. |
Hi all, and thanks for your work. I found this issue because the following example is not working for me. Not sure how easy it is to implement, because it requires some form of state - all method definitions after a bare module Foo
def a; end # not a module function
module_function
def foo; end # This is now a module function
def bar; end # This is now a module function
end |
Hey! Indeed we missed that use case. We would essentially need to remember that that |
### Motivation Closes #2653 This PR handles the other missing part of `module_function`, which is when it gets invoked with no argument. After looking into the Ruby source code, it seems that `module_func` is a flag considered as part of the visibility scope. Invoking `module_function` will both: 1. Start marking new methods as singleton methods 2. Push `private` into the stack ### Implementation I created a new `VisibilityScope` object to help us encapsulate all aspects of visibility, so that we don't forget to handle `module_func` where necessary. Then I started handling the case of `module_function` with no arguments, which essentially pushes a new scope into the stack with `module_func: true` and visibility private. ### Automated Tests Added a few tests.
When
module_function
is invoked, the given method becomes available in the singleton class and it is turned into a private method on including namespaces. For example:We need to add processing for
module_function
here. Essentially, when we find an invocation tomodule_function
, we want to:The text was updated successfully, but these errors were encountered: