Repository navigation
Type hierarchy over the language server: find_type_hierarchy, and find_implementations falling back to subtypes for a class - #2023
Open
MarioRial22 wants to merge 8 commits into
Conversation
…d_implementations falling back to subtypes for a class textDocument/prepareTypeHierarchy + typeHierarchy/subtypes|supertypes, resolved to the defining symbols; a server without a typeHierarchyProvider (MethodNotFound) answers an empty hierarchy, never an error; types outside the repository (typeshed) are skipped. find_implementations on a class/interface with no implementations reported now returns its subtypes instead of [] (pyright and pyrefly answer textDocument/implementation for methods only). The Python and TypeScript servers advertise the textDocument.typeHierarchy capability. Tests on pyrefly (subtypes, supertypes, the fallback) and on typescript-language-server 5.1.3, which has no type hierarchy (the empty contract).
… with Path.is_relative_to On GitHub's Windows runner the repository lives on D: and pyrefly's typeshed on C:, and os.path.commonpath raises ValueError for paths on different drives instead of answering. The supertypes of a class inheriting from ABC then failed on Windows instead of skipping the typeshed item, which is what the check is there to do. Path.is_relative_to answers False across drives, and it is the idiom the rest of the module already uses.
|
|
# Conflicts: # CHANGELOG.md
… the LSP facade Upstream reified the tool layer while this branch was open: an LspApi facade now holds the logic, tools delegate to it through LspApiMixin, and each facade method names its corresponding tool. FindTypeHierarchyTool was written before that existed, so the merge adapts it rather than keeping a tool that reaches for the symbol retriever directly: - LspApi.find_type_hierarchy, mirroring find_implementations (the closest sibling: same LspSymbolCollection, same include_info handling), marked optional and carrying corresponding_tool=FindTypeHierarchyTool. - FindTypeHierarchyTool keeps its signature and docstring and delegates to that method, like FindReferencingSymbolsTool and the rest. The retriever methods this stands on (find_subtype_symbols / find_supertype_symbols and the find_implementations fallback in symbol.py) merged unchanged.
# Conflicts: # CHANGELOG.md
opcode81
added
the
internal discussion
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the issue "
find_implementationsanswers[]for a class" (see the linked issue).SolidLanguageServer.request_type_hierarchy_subtypes/_supertypes:textDocument/prepareTypeHierarchy+typeHierarchy/subtypes|supertypes, each item resolved to the symbol that defines it (therequest_implementing_symbolsshape). A server that answers MethodNotFound has no type hierarchy: the result is empty, never an error. Types outside the repository (typeshed) are skipped.LanguageServerSymbolRetriever.find_subtype_symbols/find_supertype_symbols, andfind_implementing_symbolsfalling back to the subtypes when the server reports no implementations for a Class or Interface — pyrefly and pyright answertextDocument/implementationfor methods only.FindTypeHierarchyTool(find_type_hierarchy, optional): subtypes or supertypes of a class/interface, one level per call,include_infolikefind_implementations.textDocument.typeHierarchyclient capability.test/conftest.py:project_with_explicit_ls_context, a project that runs the GIVEN language server —project_with_ls_contextloads the repo's ownproject.yml, which for the Python test repo means pyright whatever backend a test asked for.Tests (
test/serena/test_type_hierarchy.py): pyrefly — subtypes ofBaseService, supertypes ofDataSyncService, thefind_implementationsfallback; typescript-language-server 5.1.3, which does not implementprepareTypeHierarchy— the empty contract. pyrefly reports the whole chain (indirect descendants and ancestors included), so the assertions are supersets and the docstrings say "as the server reports them".Checklist
CONTRIBUTING.mdregarding the scope of PRs.CHANGELOG.md, which concisely describes the change.