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.

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

WIP: Properly attribute dynamically-generated methods #1984

Draft
wants to merge 3 commits into
base: uk-method-generation-improvements
Choose a base branch
from

Conversation

egiurleo
Copy link
Contributor

@egiurleo egiurleo commented Aug 9, 2024

Motivation

Implementation

Tests

paracycle and others added 3 commits August 9, 2024 20:07
We used to treat methods that didn't have a source location the same as
methods that explicitly were not defined in the current gem. That
resulted in Tapioca creating more method definitions than necessary.

We would only skip method generation for a method if the constant it was
on was an ignored type (i.e. a built-in type), so that we wouldn't keep
redefining methods for built-in types. However, for all other types,
especially types that come from other gems, we would just keep on
generating all the methods regardless of if they were defined by this
gem or not.

Moreover, the source location check was happening at the wrong location,
before unwrapping the method signature. Thus, many methods with
signatures would not be generated when the previous problem was fixed,
since our code would see them as being defined in Sorbet runtime.

The fix is to return a more fine-grained result from `method_in_gem?`
which signals yes/no/don't-have-source-location. Based on that we can
skip generating don't-have-source-location cases if they are for
built-in types and totally ignore the methods that have a source
location and are definitely not defined in the current gem.

Additionally, if we try to unwrap the method signature and we get an
exception, that means the signature block raised an error. If we
continue with the method as is, the source location checks would think
the method definition does not belong in the gem (since the method is
still wrapped), and we would thus skip the method generation. To avoid
that, the `signature_for` method is now raising a custom exception to
signal that exceptional case, so that we can at least continue
generating "a" method definition.
…efinitions that are triggered by one gem but defined in another
@egiurleo egiurleo changed the base branch from main to uk-method-generation-improvements August 9, 2024 22:13
@paracycle paracycle force-pushed the uk-method-generation-improvements branch from 6ee7756 to a11f4ce Compare August 15, 2024 22:39
@paracycle paracycle force-pushed the uk-method-generation-improvements branch from d2329a9 to 7b05810 Compare January 16, 2025 20:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants