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: extract variable suggests extracting an *ast.ImportSpec #40635

Closed
stamblerre opened this issue Aug 7, 2020 · 5 comments
Closed
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@stamblerre
Copy link
Contributor

stamblerre commented Aug 7, 2020

Screen Shot 2020-08-07 at 2 01 09 AM

I actually would expect this to create a named import for me, which might be nice, but would requiring replacing all occurrences in the file.

/cc @joshbaum

@stamblerre stamblerre added this to the gopls/v1.0.0 milestone Aug 7, 2020
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Aug 7, 2020
@muirdm
Copy link

muirdm commented Aug 7, 2020

This already works with rename, right? I think rename is a better fit than extract to variable.

@stamblerre
Copy link
Contributor Author

Oh fair point, I forgot that rename handles that. Then we should just not support extraction here.

@joshbaum
Copy link

joshbaum commented Aug 7, 2020

This is symptom of logic living in canExtractVariable. We check if it is an ast.Expr, but then leave the actual checking if its a valid ast.Expr type to extractVariable. This is why the lightbulb is on, but it won't actually do anything. Should we move this logic into canExtractVariable? We could just have a barebones switch statement in there that explicitly checks the type.

EDIT: This is actually an *ast.BasicLit, not an *ast.ImportSpec. This is why the lightbulb is showing up. It does not actually extract anything because extractVariable does not find a place to insert the extraction. In pathEnclosingInterval -> path[0] is the basic lit and path[1] is the import spec. Do we want to special case this to prevent the lightbulb?

@stamblerre
Copy link
Contributor Author

EDIT: This is actually an *ast.BasicLit, not an *ast.ImportSpec. This is why the lightbulb is showing up. It does not actually extract anything because extractVariable does not find a place to insert the extraction. In pathEnclosingInterval -> path[0] is the basic lit and path[1] is the import spec. Do we want to special case this to prevent the lightbulb?

Yes, please - let's do that.

@gopherbot
Copy link

Change https://golang.org/cl/251018 mentions this issue: internal/lsp/source: do not allow extraction of an import spec

@stamblerre stamblerre modified the milestones: gopls/v1.0.0, gopls/v0.5.0 Aug 27, 2020
@golang golang locked and limited conversation to collaborators Aug 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

4 participants