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

x/tools/gopls: wrong variable name in func literal #42794

muirdm opened this issue Nov 24, 2020 · 1 comment

x/tools/gopls: wrong variable name in func literal #42794

muirdm opened this issue Nov 24, 2020 · 1 comment


Copy link

@muirdm muirdm commented Nov 24, 2020

package main

import "go/ast"

func _() {
	var f func(ast.Node)
	f = fun<>

Completing the func literal at <> yields func(a ast.Node) {} instead of func(n ast.Node) {}. The param name should be "n" for "Node", not "a" for "ast".

We try to use an empty types.Qualifier to ignore the package name, but something clearly isn't right.

Copy link

@gopherbot gopherbot commented Dec 5, 2020

Change mentions this issue: internal/lsp/source: fix default param name generation

marwan-at-work added a commit to marwan-at-work/tools that referenced this issue Dec 23, 2020
When generating a default param name based on a type name, we want to
ignore any package qualifier. For example, if the type is "ast.Node"
we want to generate the variable name "n", so we must ignore the
"ast." qualifier. To do this we use a types.Qualifier that always
returns empty, but qualifyExpr wasn't respecting an empty qualifier
because it is doing manual ast manipulation. However, it seems like
things "just work" if you set a SelectorExpr's "X" to empty
string (i.e. only "Sel" is output when formatting).

Fixes golang/go#42794.

Change-Id: Ied86b9511e4a9550590417c5a506fe35d561d4f9
Run-TryBot: Muir Manders <>
gopls-CI: kokoro <>
TryBot-Result: Go Bot <>
Reviewed-by: Rebecca Stambler <>
Trust: Rebecca Stambler <>
Trust: Robert Findley <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants