Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add support for extend self in the indexer #2782

Open
vinistock opened this issue Oct 25, 2024 · 1 comment · May be fixed by #2855
Open

Add support for extend self in the indexer #2782

vinistock opened this issue Oct 25, 2024 · 1 comment · May be fixed by #2855
Labels
enhancement New feature or request good-first-issue Good for newcomers rubyconf-hackday server This pull request should be included in the server gem's release notes

Comments

@vinistock
Copy link
Member

If you invoke extend self in a module, every instance method added to that module becomes available as singleton methods as well, all with public visibility.

module Foo
  def bar
  end

  extend self

  def baz
  end
end

# both `bar` and `baz` are public singleton and instance methods

Handling this a bit tricky because you can invoke extend self anywhere in the body of the module. I think the right way to handle this is like this:

  • When we find an extend self, we take every instance method the module defines and add their singleton versions to the index as well
  • Additionally, we mark a new attribute on the module to remember that it has extended self
  • Then we always check if the module extended self and, if it did, any new instance method also becomes a singleton method

Since modules can be re-opened in multiple files, I think that's the only way to guarantee that we end up with an accurate representation.
@vinistock vinistock added enhancement New feature or request server This pull request should be included in the server gem's release notes good-first-issue Good for newcomers labels Oct 25, 2024
@tlemburg
Copy link

tlemburg commented Nov 14, 2024 •
edited
Loading

Handling this a bit tricky because you can invoke extend self anywhere in the body of the module. I think the right way to handle this is like this:

  • When we find an extend self, we take every instance method the module defines and add their singleton versions to the index as well
  • Additionally, we mark a new attribute on the module to remember that it has extended self
  • Then we always check if the module extended self and, if it did, any new instance method also becomes a singleton method
    Since modules can be re-opened in multiple files, I think that's the only way to guarantee that we end up with an accurate representation.

This approach seems great: as a hint, could someone point at where you'd adjust that logic and then expose to the language server that we have new singleton methods?

EDIT: Getting MUCH closer, think I have the above questions answered.

tlemburg pushed a commit to tlemburg/ruby-lsp that referenced this issue Nov 14, 2024
Add support for extend self to handle_module_operation
82b49a9 
By adding the instance methods as class methods through the
singleton mixin operations, we are able to get all instance
methods "copied" over into the class methods implicitly.

I don't think it's necessary to test whether this extend self
applies when the module is opened after being closed again,
or re-opened in another file.

Closes Shopify#2782
@tlemburg tlemburg linked a pull request Nov 14, 2024 that will close this issue
Open
tlemburg added a commit to tlemburg/ruby-lsp that referenced this issue Nov 14, 2024
@tlemburg
Add support for extend self to handle_module_operation
23fc41b 
By adding the instance methods as class methods through the
singleton mixin operations, we are able to get all instance
methods "copied" over into the class methods implicitly.

I don't think it's necessary to test whether this extend self
applies when the module is opened after being closed again,
or re-opened in another file.

Closes Shopify#2782
tlemburg added a commit to tlemburg/ruby-lsp that referenced this issue Nov 18, 2024
@tlemburg
Add support for extend self to handle_module_operation
69634b6 
By adding the instance methods as class methods through the
singleton mixin operations, we are able to get all instance
methods "copied" over into the class methods implicitly.

I don't think it's necessary to test whether this extend self
applies when the module is opened after being closed again,
or re-opened in another file.

Closes Shopify#2782
tlemburg added a commit to tlemburg/ruby-lsp that referenced this issue Nov 19, 2024
@tlemburg
Add support for extend self to handle_module_operation
935eebd 
By adding the instance methods as class methods through the
singleton mixin operations, we are able to get all instance
methods "copied" over into the class methods implicitly.

I don't think it's necessary to test whether this extend self
applies when the module is opened after being closed again,
or re-opened in another file.

Closes Shopify#2782
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request good-first-issue Good for newcomers rubyconf-hackday server This pull request should be included in the server gem's release notes
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add support for extend self to handle_module_operation tlemburg/ruby-lsp
3 participants
@andyw8 @tlemburg @vinistock