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

Testing @grncdr's hacks #43

Open
wants to merge 32 commits into
base: main
Choose a base branch
from
Open

Conversation

iftheshoefritz
Copy link
Owner

No description provided.

@alisnic
Copy link
Collaborator

alisnic commented Nov 2, 2022

@iftheshoefritz please do a pull from master, let's see what CI says

@iftheshoefritz
Copy link
Owner Author

@alisnic I think @grncdr has done that already, I see your latest commits on this branch

@grncdr
Copy link
Collaborator

grncdr commented Nov 13, 2022

Hey sorry about the lack of communication, I've been pretty busy lately and I wanted to get some more testing of this branch done before opening a PR, but I really haven't had the time.

About the CI failures, I haven't looked to closely but I suspect they won't be too hard to fix. There's probably conflicts between the types.yml and my changes in model.rb. It probably makes mores sense to split this PR up into multiple PRs.

Easy stuff

Everything up to and including 6989d59 (compare), (plus 0338071 which fixes a regression) is more or less harmless.

Blocked on solargraph changes

0f9e4af depends on castwide/solargraph#602 which hasn't seen a lot of movement. I get the impression @castwide is also very busy, so if anybody has ideas on how to streamline that PR I'm all ears.

The bigger stuff

d6a9b12 is the main change, and it's a pretty radical departure from the approach taken in this gem so far. The commit message explains the what/why in more detail, but to summarize: YARD types and the Solargraph type-checker are not capable of expressing ActiveRecord APIs in a truly generic fashion. Generating a load of types/pins at runtime gives a far better result, and honestly isn't that much more work.

I'm pretty sure that this contradicts the approach being taken with types.yml (and indeed I removed a few types from there) but like I mentioned at the top, I haven't yet looked closely into the test failures. It would be very cool if either/both of you could read through that commit (d6a9b12) and give me a 👍 / 👎 on the approach. I'm happy to fix/add test cases, but if nobody else wants to maintain this, I'll just stick to my own fork.

@iftheshoefritz
Copy link
Owner Author

@grncdr I agree with your assessment, thanks for explaining so clearly in that commit. I'm all for continuing as you have, let's move away from trying to make YARD do things it can't.

@@ -1,4 +1,4 @@
lib = File.expand_path('../lib', __FILE__)
lib = File.expand_path('lib', __dir__)
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is interesting, what is the importance of the difference here? (not pushing back, just curious)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I think that's an autofix by Rubocop.

grncdr and others added 12 commits May 20, 2023 19:56
These contained a load of duplicated definitions for methods that are
inherited from Module. This will make tests a teensy tiny bit faster,
but mostly makes these files actually sort of useful.

These changes were made manually, the generate_definitions.rb script
should probably be updated to be a bit more precise, but we can deal
with that the next time somebody feels like running it.
If another test instantiates the Annotate class with a schema is present first, this test would fail.

Singletons ...
This (as far as I know) matches what Rails will do when it doesn't
understand a database type.
This a more accurate represenation of what ActiveRecord actually does at
runtime, and therefore gives better code suggestions when dealing with
associations and model classes.

I've settled on this as being the best compromise after trying a few
different approaches. There are two "challenges" that I believe can't be
met any other way (at this time).

1. It is not possible to write a return type annotation for the methods
   of various ActiveRecord mixins that will be correct for both a model
   class (e.g. Person.where) and relation (e.g. people.where). [0], [1]
2. It is not possible to represent ActiveRecords "class methods are also
   relation methods" behaviour without model-specific relation types.

It's conceivable that Solargraph could change it's interpretation of [self]
on class methods to solve the first challenge, but the second one really
forces our hand. In order to represent this correctly, Solargraph would
need support for method-missing delegation, **and** delegating those
missing methods to an associated/generic type.

Given @castwide is working on RBS support and the Ruby ecosystem is
likely to move that way in the future, it seems pragmatic to eat the
cost repetition / manual labour in this gem rather than try to push YARD
types into supporting that degree of type-level programming. 😅

[0]: castwide/solargraph#592
[1]: lsegal/yard#1257
Setting this binding the models hidden relation type makes it possible
to refer to other scopes and the ActiveRecord API with correct types
when defining a scope.
This fixes errors when the typecheck reporter is enabled.
@iftheshoefritz
Copy link
Owner Author

@grncdr over in #59 I can see that although bundle list says that all the gems we need are available to bundler, none of the test app's gems are present in vendor/bundle. These are the only gems that find vendor -name Gemfile shows:

vendor/bundle/ruby/3.1.0/gems/net-pop-0.1.2/Gemfile
vendor/bundle/ruby/3.1.0/gems/solargraph-0.49.0/Gemfile
vendor/bundle/ruby/3.1.0/gems/net-imap-0.3.6/Gemfile
vendor/bundle/ruby/3.1.0/gems/crass-1.0.6/Gemfile
vendor/bundle/ruby/3.1.0/gems/orm_adapter-0.5.0/Gemfile
vendor/bundle/ruby/3.1.0/gems/irb-1.7.0/Gemfile
vendor/bundle/ruby/3.1.0/gems/debug-1.8.0/Gemfile
vendor/bundle/ruby/3.1.0/gems/bcrypt-3.1.19/Gemfile
vendor/bundle/ruby/3.1.0/gems/mini_mime-1.1.2/Gemfile
vendor/bundle/ruby/3.1.0/gems/nio4r-2.5.9/Gemfile
vendor/bundle/ruby/3.1.0/gems/reverse_markdown-2.1.1/Gemfile
vendor/bundle/ruby/3.1.0/gems/e2mmap-0.1.0/Gemfile
vendor/bundle/ruby/3.1.0/gems/method_source-1.0.0/Gemfile
vendor/bundle/ruby/3.1.0/gems/benchmark-0.2.1/Gemfile
vendor/bundle/ruby/3.1.0/gems/net-protocol-0.2.1/Gemfile
vendor/bundle/ruby/3.1.0/gems/nokogiri-1.15.2-x86_64-linux/Gemfile
vendor/bundle/ruby/3.1.0/gems/bundler-audit-0.9.1/spec/bundle/insecure_sources/Gemfile
vendor/bundle/ruby/3.1.0/gems/bundler-audit-0.9.1/spec/bundle/unpatched_gems_with_dot_configuration/Gemfile
vendor/bundle/ruby/3.1.0/gems/bundler-audit-0.9.1/spec/bundle/unpatched_gems/Gemfile
vendor/bundle/ruby/3.1.0/gems/bundler-audit-0.9.1/spec/bundle/secure/Gemfile
vendor/bundle/ruby/3.1.0/gems/bundler-audit-0.9.1/Gemfile
vendor/bundle/ruby/3.1.0/gems/regexp_parser-2.8.1/Gemfile
vendor/bundle/ruby/3.1.0/gems/backport-1.2.0/Gemfile
vendor/bundle/ruby/3.1.0/gems/concurrent-ruby-1.2.2/Gemfile
vendor/bundle/ruby/3.1.0/gems/timeout-0.4.0/Gemfile
vendor/bundle/ruby/3.1.0/gems/rake-12.3.3/Gemfile
vendor/bundle/ruby/3.1.0/gems/warden-1.2.9/Gemfile
vendor/bundle/ruby/3.1.0/gems/rbs-2.8.4/Gemfile
vendor/bundle/ruby/3.1.0/gems/sqlite3-1.6.3-x86_64-linux/Gemfile

This looks like it might just be the solargraph-rails dependencies that are installed there.

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.

3 participants