[PATCH] D44226: [clangd] Add -log-lsp-to-stderr option

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.
Herald added a subscriber: jkorous.

Hey Simon,

Sorry this patch got stalled. I hope you're still interested!
I agree there's space for providing some high-signal information about error conditions to power users/potential developers/administrators, even if it's not "polished" for end-users.

What are the semantics we want for these log levels? My guess is we need a third one:

1. it seems clear we want a level that indicates likely problems, with minimal noise. You want this, and this is useful for monitoring production/cloud issues too.
2. it may be useful to add context like LSP method names and "rebuilding preamble" to understand the context of errors and crashes. I think this is what Ilya was pushing for.
3. we also want to log details that allow you to see what's going on with only the log to go on. This is stuff like full LSP messages. I think it's important that we can do this with a production build.
4. finer-grained debugging things can probably be done in a targeted way using `LLVM_DEBUG` (CodeComplete has some of this for debugging scoring signals)

What do you think about 1=`elog()` (e for Error), 2=`log()`, 3=`vlog()` (v for Verbose), and using LLVM_DEBUG for 4?

I don't have a strong opinion of what the default should be long term, but either 1 with `-v` and `-vv` to change,  or 2 with `-q` and `-v`, seem reasonable...

(Internally at google we use something like glog <https://github.com/google/glog> which calls these levels ERROR, INFO, VLOG(1) and VLOG(2), with INFO as default - this convention explains some of our confusion over the semantics of vlog!)

If you don't think we need a third level, or don't have time for it now, I'm pretty happy with this patch as it is but would suggest rename of `log`,`vlog` --> `elog`,`log` to make it clearer that the former is for problems only.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44226