jkorous abandoned this revision.
jkorous added a comment.
Morphed into https://reviews.llvm.org/D54799
Repository:
rCTE Clang Tools Extra
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D54529/new/
https://reviews.llvm.org/D54529
___
cfe-co
sammccall added a comment.
OK, sounds like we have something to move forward with. I'd suggest we start
with an operation returning {SymbolID, scope qualifiers, unqualified name, USR}
and ignoring location for now, unless you have an immediate need. Reason being
this sidesteps the index questio
arphaman added a comment.
I don't think we should be using `textDocument/definition` here, and I agree
with Sam that a new method would be better. We don't actually need the semantic
guarantees/constrains imposed by LSP's description of
`textDocument/definition`, as we want to find any declara
sammccall added a comment.
@benlangmuir: I hadn't seen your comment while replying, sorry for any
confusion...
> The most critical piece of this is being able to ask "what symbol is at this
> location" and correlate that with index queries.
This makes sense (at least doing follow-up index quer
sammccall added a comment.
If we're extending the API, we should be careful to do it in an orthogonal and
reasonable general way. Apple may not need USR in other places now, but there
are users other than Apple and times other than today :-)
One of the reasons this looks odd is the method is "f
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
jkorous added a comment.
Correction - I asked offline about our intended use of USR in LSP and it seems
we might want to receive it as part of other responses too. Nothing specific
for now but it's probable that it won't be just this singular case.
Repository:
rCTE Clang Tools Extra
https:/
jkorous added a comment.
We are also discussing creating separate method as we'll likely want to add
other data to the response in the future. Would you prefer USR not to be in the
standard part of LSP but only in our extension?
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D5
jkorous added a comment.
Hi Sam!
I am aware of clangd using SymbolID. We basically need USR for integration with
our external indexing service. We don't plan to systematically use it in the
protocol and I am not aware of any other requirement for using USR in LSP -
will double check that to be
jkorous added a comment.
One more thing - shall I create new client capability flag for this?
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
sammccall added a comment.
Hi Jan,
Clangd uses SymbolIDs rather than USRs, to identify symbols.
However these are used only internally, and for extension point APIs
(SymbolIndex), and not actually exposed over the wire.
Can you explain more about the need to identify the symbol in go-to-definit
jkorous created this revision.
jkorous added reviewers: sammccall, ilya-biryukov, arphaman, benlangmuir.
jkorous added a project: clang-tools-extra.
Herald added subscribers: cfe-commits, kadircet, dexonsmith, MaskRay, ioeric.
We need a way for given code position to get the best definition/declar
12 matches
Mail list logo
