gopls/hover: show named func type doc when hovering over func literal#633
Closed
abhay1999 wants to merge 4 commits intogolang:masterfrom
Closed
gopls/hover: show named func type doc when hovering over func literal#633abhay1999 wants to merge 4 commits intogolang:masterfrom
abhay1999 wants to merge 4 commits intogolang:masterfrom
Conversation
…re a declaration When a user places the cursor immediately after "//" (with no trailing space) on a line directly above a declaration, gopls already suggests the declaration name as a completion candidate. However the suggested insert text lacked the conventional space, producing "//Name" instead of the proper Go doc comment form "// Name". Detect this case in populateCommentCompletions (cursor at slash+2 with comment text exactly "//") and set a new commentNeedsLeadingSpace flag on the completionContext. item() checks the flag and prepends a space to the insert text (and snippet), so accepting the completion yields "// Name". A marker test is added to comment.txt that asserts the candidate appears when the cursor is right after "//", above a function declaration. Fixes golang/go#76374
…es after // Previously, commentNeedsLeadingSpace was only set when the cursor was exactly at slash+2 and the comment text was exactly "//". This missed the case where the user had partially typed an identifier (e.g. "//Foo") and triggered completion mid-word. Fix: use c.surrounding.start (the start of the edit range, set by setSurroundingForComment) instead. If the edit range starts at slash+2, there is no space between "//" and the identifier being replaced, so completions should prepend a space. Also add a marker test for the partial-prefix case.
implFuncs handles the "(" paren of a CallExpr as an entry point for
finding dynamic function-call implementations. When the call is not
dynamic (e.g. err.Error(), len(""), or a type conversion), it
previously returned a hard error "not a dynamic function call" which
blocked the method-sets fallback and produced a confusing message.
Change the non-dynamic case to return errNotHandled instead, which
lets the caller fall through to the regular method-sets algorithm.
That algorithm also cannot find an implementation from a bare "(" (it
needs an identifier), so it returns "no identifier found" — a standard
error that editors handle gracefully — rather than a gopls-specific
message.
The fix is consistent with the treatment of "(" in
textDocument/references (#76872) and preserves the intended separation
between dynamic-function-type queries (keyed by "func" or "(") and
interface-method queries (keyed by the method name identifier).
Update the affected marker tests to expect "no identifier found".
Fixes golang/go#77784
When a func literal is implicitly converted to a named function type
(e.g. fs.WalkDirFunc), hovering over its "func" keyword now shows the
documentation and signature of that named type, with a link to pkg.go.dev.
Previously, hovering over "func" in:
filepath.WalkDir(dir, func(path string, d fs.DirEntry, err error) error {
...
})
showed only the anonymous signature "func(path string, d fs.DirEntry,
err error) error". Now it shows the docs for fs.WalkDirFunc, which is
often the information the user actually wants.
Implementation:
- Detect the case in the hover switch: when cur.Node() is *ast.FuncType
and the cursor is at the "func" token and the parent is a *ast.FuncLit.
- Use typesutil.TypesFromContext to find the named function type the
literal must satisfy.
- Load the declaring package and build a hoverResult with the named
type's documentation, signature, and pkg.go.dev link.
- If no named type is found, fall back to the existing anonymous-type
hover behavior.
Add a marker test in hover/funclittype.txt covering both cases.
Fixes golang/go#76191
Contributor
Author
|
Replacing with a clean PR that contains only this commit (previous PR had unrelated commits from other branches). |
|
See #634 then |
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
2 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.
Problem
When a func literal is implicitly converted to a named function type
(e.g.
fs.WalkDirFunc), hovering over itsfunckeyword only showedthe anonymous signature — not the documentation for the named type
that the user likely wants.
For example, hovering over
funcin:previously showed:
The user had to first jump to
filepath.WalkDir's definition, thennavigate to
fs.WalkDirFunc, just to see its documentation.Fix
When
cur.Node()is*ast.FuncTypewith the cursor at thefunctoken and the parent is a
*ast.FuncLit, the newhoverFuncLitfunction:
typesutil.TypesFromContexton the func literal's cursor tofind the named function type the literal must satisfy.
NarrowestDeclaringPackageandextracts the doc comment and signature.
hoverResultwith the named type's documentation,signature,
SymbolName, and apkg.go.devlink.If no named type is found (e.g.
f := func(x int) int { ... }), itfalls back to the existing behavior of showing the anonymous type.
Note:
FindByPosat aFuncLit'sfunctoken returns the inner*ast.FuncTypenode (not*ast.FuncLit), so the code checks theparent node to detect the FuncLit context.
Test
Added
gopls/internal/test/marker/testdata/hover/funclittype.txtwith:WalkFunc): hover shows the doc + link.Fixes golang/go#76191