benlangmuir added a comment. @sammccall RE using USRs: we want to integrate clangd into a larger source tooling system that is already using USRs extensively to identify symbols. The most obvious case is that we have an index outside of clangd that uses USRs from clang-the-compiler, so exposing USRs in clangd lets us integrate information from both places. The most critical piece of this is being able to ask "what symbol is at this location" and correlate that with index queries. Beyond this one case, my experience is that any time a language service API is providing information about a symbol or list of symbols it may be useful to add the USR (e.g. hover, definition or workspace symbols).
You mentioned a concern that this would make us diverge from LSP - could you expand on that? I think for any existing requests the USR is purely additive. If the concern is about affecting the return values of existing queries, would it help to put this behind a configuration option? There is also an extension that might be interesting to look at here: https://github.com/sourcegraph/language-server-protocol/blob/master/extension-symbol-descriptor.md In this case the symbol descriptor is opaque, but in practice our use case would require knowing how to dig out a USR string. For the specific use case of getting cursor info, as @jkorous mentioned we might want to move this out of "definition". Our experience with sourcekitd for Swift is that a cursor info request is a useful place to put an assortment of information that may grow over time - e.g. name, type name, USR, type USR, symbol kind, local declaration/definition location, etc. Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D54529 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
