FWIW I opted for this when using a shared gopls daemon (#34111): -debug is enabled on the daemon by default (though some users have already asked to be able to disable it, so I'll support that as well).

I also used an extra gopls/handshake RPC to exchange debug information between forwarder and daemon, including the debug port and the location of logs. We could perhaps rename and generalize this to expose this information to LSP clients.

-rpc.trace by default is a good idea! I'm not sure however that I think exposing the debug port is.

The gopls process often runs on a local environment, and people that use multi user systems will probably not be aware of the fact that "anyone" on that machine can connect to their gopls instance. The main concern is that the contents of the file being edited is available directly and that makes it trivial to grab information.

@heschik made the point that turning on -rpc.trace by default would make logs difficult to parse for users who are just looking to find a single error message, so I think we should maybe keep it off by default.

I am not sure about turning on the debug server by default because of the concerns that @leitzler mentioned, but maybe we can start with a flag that makes it a bit easier to enable and then go from there.

@stamblerre what would an easier flag look like? -debug=<addr> is pretty easy. The one thing I wish were easier is finding the port when run with -debug=:0 (you have to scrape the start of the logs).

One of the nice things about daemon mode is that it was easy to hook up some debugging over jsonrpc2 without a debug server (https://golang.org/cl/222669). I wonder if we could do the same for sidecar serving (i.e., add a debugHandler to the jsonrpc2 handler stack and add functionality to the vscode client to inspect debug information).

Pie in the sky: If we standardized a jsonrpc2 protocol (meta-protocol?) for debug information, we could even turn the current debug webserver into a separate jsonrpc2 client process that can be attached even after the gopls server is started...

Don't want to derail this discussion though! My opinion is that the current state, while suboptimal, is better than enabling -rpc.trace or -debug by default.

Don't want to derail this discussion though! My opinion is that the current state, while suboptimal, is better than enabling -rpc.trace or -debug by default.

That's fair. I was thinking something like -debug=auto which could automatically turn on -rpc.trace and also start up the debug server on a random port, which could then show the link to the user with window/showMessage.

That's fair. I was thinking something like -debug=auto which could automatically turn on -rpc.trace and also start up the debug server on a random port, which could then show the link to the user with window/showMessage.

Not sure about coupling -debug and -rpc.trace, but I really like the idea of showing the debug link with window/showMessage. This would be very useful with -debug=:0. That seems worthwhile in any case (we might also want to consider this for the logfile location).

FYI - in vscode-go, we have client-side tracing that can be enabled/disabled anytime without restarting the gopls. So for vscode-go, -rpc.trace is not critical. But the debug server may be useful.