x/tools/gopls: erroneous "go.sum is out of sync with go.mod" warning for nested module #59458
Comments
|
Thank you for the report. I can reproduce with gopls, and with the Go command: |
|
This is not a However, the command So, I would say that this is a bug in the query that |
So you're saying that this query also checks for the package ./internal/postprocessor inside the cloud.google.com/go module, right?
So in the presence of a go.work file using dirA, dirB, dirC, we'd have to call go/packages.Load("./...") three times, once from each dir, right? |
Not that package specifically, because it already knows that that one is in the main module. But that pattern would also match packages like
Hmm... You could do that, yes. You could also give directory paths instead of import paths, I think: I thought we also had a proposal somewhere about allowing See also: |
We have the absolute absolute paths available, so it sounds like this is the way to go.
FWIW that wouldn't help us here, because we don't really want to get into the business of finding a common root for otherwise unrelated dirs (and it shouldn't matter where the GOWORK value lives). Thanks for the explanation. This is a long standing gopls bug: we've loaded |
Maybe #51283 is what you were thinking of, though it's more of a tracking issue with Thinking label than a proposal. |
|
Change https://go.dev/cl/485840 mentions this issue: |
|
@bcmills I'm working on fixing this in CL 485840, linked above. This fix is failing on windows only: Test is defined here: This is a strange failure mode. On one hand the go command appears to be correctly computing the relative directory paths (see the "directory prefix"), yet the query fails. |
|
The It is using slashes to separate the path elements, where it should be using |
|
@bcmills thanks, I'll see if I can fix the failure by using the correct separators. However, I'll also note that this test was previously succeeding. It seems inconsistent that loading |
Agreed! We probably have a path-cleaning bug in |
|
Aha, so I have tests passing now. I don't think the problem was the GOWORK environment variable. Rather, it appears to be necessary to use We have other tests for GOWORK that don't fail. The only difference is that in this case, the GOWORK value is outside the workspace directory. |
|
Ah, right. Slash-separated |
You're right: the real problem is that the absolute paths use a mix of In any case, since this is such a weird edge case that wouldn't reasonably arise in practice, I don't think it's worth considering this a Go command bug. |
Um... I didn't say that. 😅 |
|
Thank you 😄 |
|
Change https://go.dev/cl/487136 mentions this issue: |
This change does additional filtering of intermediate test variants for the cases where we invoke type checking indirectly (through filecached derivatives) not via Snapshot.TypeCheck. Also: - document the head-spinning subtlety of ITVs. - change RemoveIntermediateTestVariants to use a pointer to a slice so that it is impossible to forget to use the result. D'oh! Fixes golang/go#59458 Change-Id: I156385456cefeb9dc3a84f23db3b2fa5ef9f244a Reviewed-on: https://go-review.googlesource.com/c/tools/+/487136 Auto-Submit: Alan Donovan <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Alan Donovan <[email protected]> Reviewed-by: Robert Findley <[email protected]>
gopls version
go env
What did you do?
Open my editor, vscode to do some work.
What did you expect to see?
A working editor
What did you see instead?
Editor and settings
Notes
go mod tidyproduces no diffgo listcommand that produced this error, although I was not sure how to get the exact command. This may actually be a go list issue thoughgo mod vendorand my editor works fine. When I do this it does not vendor the module that the editor is complains aboutcloud.google.com/go, rightfully soVendor modules.txt
The text was updated successfully, but these errors were encountered: