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

x/tools/gopls: extract variable suggests extracting an *ast.ImportSpec #40635

stamblerre opened this issue Aug 7, 2020 · 5 comments
Labels
Milestone

Comments

@stamblerre
Copy link
Contributor

@stamblerre 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
@muirdm
Copy link

@muirdm 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

@stamblerre stamblerre commented Aug 7, 2020

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

@joshbaum
Copy link

@joshbaum 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

@stamblerre stamblerre commented Aug 10, 2020

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.

@stamblerre stamblerre added this to In Progress in gopls/v1.0.0 Aug 26, 2020
@stamblerre stamblerre moved this from In Progress to To Do in gopls/v1.0.0 Aug 26, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Aug 27, 2020

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
gopls/v1.0.0 automation moved this from Bugs to Closed Aug 27, 2020
@stamblerre stamblerre removed this from Closed in gopls/v1.0.0 Aug 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.