Reproduce solargraph-rspec issue#1107
Conversation
YARD-parsed namespaces weren't correctly setting their gates, leading to unresolved types from methods.
Also replaces 'include' logic with call to ApiMap::Constants Fixes castwide#1099
1) Prefer closures with more gates, to maximize compatibility 2) Look at basename of location, to make choice consistent
This takes out some lower value combinations - ideally we could keep the number of jobs to <= 20, which is the max that GHA will run simultaneously here.
Found in the Solargraph::Pin::DelegatedMethod class in strong typechecking in #12
…another_ambiguous_type
…nother_ambiguous_type
…nother_ambiguous_type
…node_modules_stubs
…-specs' into try_again_removing_node_modules_stubs
…-specs' into repro_solargraph_rspec_issue
…graph_rspec_issue
…largraph_rspec_issue
|
Heads up @lekemula - will see if I can figure out what's going on. Will be a good excuse to get set up with solargraph-rspec! |
In an upcoming solargraph PR (see castwide/solargraph#1107 as an example), we won't be able to rely on resolving RSpec constants whose gem names we don't provide using the 'require' convention. That said, we also should not be caching as aggressively, either - so I'd recommend dropping this spec workaround, which seems to resolve the issue seen in the PR above.
|
Thank you so much @apiology for being cautious here - this would be way more difficult to resolve if we would have noticed it at some later point.
Absolutely! @castwide, I would appreciate it if we could merge #1087 in, sooner rather than later, to prevent more cases like this. 🙏 |
|
OK, I believe that this is a false alarm - lekemula/solargraph-rspec#26 is a spec-only change on the solargraph-rails side that should resolve it. If @lekemula agrees, we can rerun the test workflow here once the PR is merged. |
This matches a future Solargraph change which seems to be more conservative including gems while resolving constants - see castwide/solargraph#1107 for an example failure.
|
@lekemula and I are closing in on a fix; I'll close this as it doesn't reflect an issue on the Solargraph side as far as I can see. |
This matches a future Solargraph change which seems to be more conservative including gems while resolving constants - see castwide/solargraph#1107 for an example failure.
2 participants
I hit a failure in the solargraph-rspec specs while putting together a new merge branch. It looks like it can be reproduced with the combination of:
Any two together do not reproduce it.