x/tools/gopls: completion for struct literal inserts package name even if already in prefix #34872
Comments
gopherbot
added
Tools
zikaeroh
changed the title
|
/cc @muirrn |
|
Change https://golang.org/cl/201200 mentions this issue: |
|
Thanks! Let me know if the above CL doesn't resolve it for you. |
|
Not quite. A corner case using my example above is I realized that I worded my original issue in the form of "this completion inserts the wrong thing". However, I'm noticing that |
|
Just accept the completion before you type the dot! 😛
That would be cool, but we don't do anything like that yet. I'll play with it a bit.
I'd prefer not to do that since it amounts to inserting an "invalid" completion. Maybe better than nothing, though.
That is intentional for now. The "literal" completions are in addition to the normal completions. There isn't much of a downside to including maybe useless candidates, so we err on the side of including things. |
I don't get this sort of literal completion without fully typing the package name and dot, at least not immediately. Basically, I can do the equivalent of |
Ah, sounds like the package wasn't imported the first time. I was playing with something that would deep search into unimported packages, but that resulted in too many junk candidates. However, it seems like we could at least search into the expected type's package, even if it isn't imported yet. |
|
No, the package is imported. I haven't been taking about unimported completions, just ones solely from existing imports. I'm busy at the moment, but I'll try and show you how to reproduce it in my real project. |
|
What I've been doing to test this is by going to this part of the code: https://github.com/hortbot/hortbot/blob/ec47ba4e9d9a5fefddf74c681ce4f003d2feac18/internal/bot/cmd_repeat.go#L99 then adding in It's a big project, but you shouldn't need to do anything other than the above. Hopefully that helps, though I think I've sorta derailed this from the original prefix issue... 😃 |
|
I updated https://go-review.googlesource.com/c/tools/+/201200/, can you try it again?
Seems to work fine for me in Emacs :) I think you might be hitting microsoft/vscode#64367 (comment) |
|
Had the chance to check, and I think the CL is working well. Agreed on the VS Code issue (it wasn't related anyway). |
Previously we unconditionally qualified literal candidate types with
their package. For example:
var buf *bytes.Buffer
buf = &bytes.Bu<>
would complete to:
buf = &bytes.bytes.Buffer{}
Now we don't qualify the type if the cursor position is in the
selector of an *ast.SelectorExpr. We only generate literal candidates
for type names, so if we are in a selector then we can assume it is a
package qualified type (as opposed to an object field).
We also handle the insertion of "&" for literal pointers better. If you are in
the selector of an *ast.SelectorExpr, we prepend the "&" to the beginning of the
expression rather than the selector. For example, you will end up with
"&bytes.Buffer{}" instead of "bytes.&Buffer{}".
Updates golang/go#34872.
Change-Id: I812aa809cd4e649a429853386789f80033412814
Reviewed-on: https://go-review.googlesource.com/c/tools/+/201200
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
|
Any reason that CL was an "Updates" rather than "Fixes"? |
|
I didn't want to jump to conclusions since I keep missing things. If everything looks good, please close it out. |
|
As far as I can tell from my usage, this is fixed (and the |
What did you do?
In one package:
In another:
There will be a completion for
some.Struct{}in the list.What did you expect to see?
When selected, the completion expands to give the final code
s = &some.Struct{}What did you see instead?
Accepting the completion results in
s = &some.some.Struct{}.Build info
Go info
The text was updated successfully, but these errors were encountered: