Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upx/tools/gopls: first Configuration does not happen as part of handling Initialized #35817
Comments
This comment has been minimized.
This comment has been minimized.
Another reason this needs to happen as part of the handling of |
As a temporary, fragile workaround for golang/go#35817, we block the initialisation of govim until we have received the Configuration call from gopls. Per the TODO message in the code, this is fragile and best and built on broken assumptions at worst. But it should suffice for now.
As a temporary, fragile workaround for This is a rather fragile workaround for golang/go#35817, we block the initialisation of govim until we have received the Configuration call from gopls. It's fragile because we are relying on gopls not handling any requests until the response to Configuration is received and processed. In practice this appears to currently be the case but there is no guarantee of this going forward. Rather we hope that a fix for golang/go#35817 lands sooner rather than later at whic point this workaround can go. We also use a lock here because, despite it appearing that will only be a single Configuration call and that if there were more they would be serial, we can't rely on this. This is fragile and best and built on broken assumptions at worst. But it should suffice for now.
As a temporary, fragile workaround for This is a rather fragile workaround for golang/go#35817, we block the initialisation of govim until we have received the Configuration call from gopls. It's fragile because we are relying on gopls not handling any requests until the response to Configuration is received and processed. In practice this appears to currently be the case but there is no guarantee of this going forward. Rather we hope that a fix for golang/go#35817 lands sooner rather than later at whic point this workaround can go. We also use a lock here because, despite it appearing that will only be a single Configuration call and that if there were more they would be serial, we can't rely on this. This is fragile and best and built on broken assumptions at worst. But it should suffice for now.
As a temporary, fragile workaround for This is a rather fragile workaround for golang/go#35817, we block the initialisation of govim until we have received the Configuration call from gopls. It's fragile because we are relying on gopls not handling any requests until the response to Configuration is received and processed. In practice this appears to currently be the case but there is no guarantee of this going forward. Rather we hope that a fix for golang/go#35817 lands sooner rather than later at whic point this workaround can go. We also use a lock here because, despite it appearing that will only be a single Configuration call and that if there were more they would be serial, we can't rely on this. This is fragile and best and built on broken assumptions at worst. But it should suffice for now.
…593) As a temporary, fragile workaround for This is a rather fragile workaround for golang/go#35817, we block the initialisation of govim until we have received the Configuration call from gopls. It's fragile because we are relying on gopls not handling any requests until the response to Configuration is received and processed. In practice this appears to currently be the case but there is no guarantee of this going forward. Rather we hope that a fix for golang/go#35817 lands sooner rather than later at whic point this workaround can go. We also use a lock here because, despite it appearing that will only be a single Configuration call and that if there were more they would be serial, we can't rely on this. This is fragile and best and built on broken assumptions at worst. But it should suffice for now.
This comment has been minimized.
This comment has been minimized.
I expect that this is more likely an issue in the way that we are writing out the logs, because the initialized request definitely asks for configurations before proceeding. The |
This comment has been minimized.
This comment has been minimized.
I'm not entirely sure on that, because this was also confirmed by the Here's a similar snippet from our
|
This comment has been minimized.
This comment has been minimized.
Can you try reproducing this on a file with build tags or some other configuration you would expect |
This comment has been minimized.
This comment has been minimized.
@stamblerre kindly explained offline that this ordering of these notifications/calls is actually not significant, because all aspects in I therefore incorrectly attributed these seemingly "out of order" logs to be the root cause of #35933. But adding a sleep in Hence closing. |
What version of Go are you using (
go version
)?Note that
github.com/myitcvforks/tools v0.0.0-20191119111301-0222b4b716c6
andgithub.com/myitcvforks/tools/gopls v0.0.0-20191119111301-0222b4b716c6
correspond to thex/tools
95cb2a1a7eae2d74d8211d4930f76e8ccd5e124f with 80313e1ba7181ff88576941b25b4beb004e348db cherry picked on top. Reason being, we can't move beyond 95cb2a1a7eae2d74d8211d4930f76e8ccd5e124f because otherwise we start tripping over the mistmatched versions problem described in #35114Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
We have a
govim
test that is looking to verify the behaviour of setting the"env"
config setting withGOFLAGS=-mod=reaonly
.However the issue we are seeing is that the initial
Configuration
call fromgopls
togovim
happens as follows:govim -> gopls: Initialize()
govim -> gopls: Initialized()
(notification)govim -> gopls: didOpen("main.go")
govim -> gopls: didChange("main.go")
gopls -> govim: Configuration()
i.e. it's not happening as part of handling the
Initialized
notification fromgovim
.What did you expect to see?
This doesn't appear to be specified in the LSP spec https://microsoft.github.io/language-server-protocol/specifications/specification-3-14/#initialized but not calling
Configuration
as part of handling theInitialized
notification means that the client has no way of registering configuration that should be applied "from the start".e.g. in this case, setting
"env"
to includeGOFLAGS=-mod=reaonly
. If this does not happen during the handling ofInitialized
then thego.mod
file will likely already have been modified by the time the results ofConfiguration
come to be processed.One could argue that the client could instead send the
DidChangeConfiguration
notification immediately afterInitialized
but this is not specified either, so we can't be guaranteed that all clients will do this. Whereas callingConfiguration
as part of the handling ofInitialized
(not afterwards because otherwise this creates a race) seems safe.What did you see instead?
As above.
gopls
log as follows:fail.log
cc @stamblerre