textDocument/definition vs textDocument/declaration

Hi everyone,

I have one question about textDocument/definition processing. Clangd uses symbol’s declaration instead of definition if it can’t find it. This behavior is completely ok for some cases, for instance when somebody wants to goto for system functions (for instance, memcpy) where definition can’t be provided. From other side the behaviour confuses users for non-system code: clangd starts to work properly after some time (when the index is built)

I want to get info about the event (declaration was used instead of definition) on LSP client side. It can be used for additional processing for such events as well as for monitoring purposes. I consider different option how it can be implemented. Unfortunately I could not find how the situation can be processed with current version of the LSP protocol and it looks like some extension has to be implemented to support it.

I consider LocationLink as the base point and want to add an optional field into it:

interface LocationLink {
...
	/**
	 * Declaration was used as a fallback for definition
	 */
	declFallback?: boolean;;
}

What do you think about it? Is there a way to get the info with minimal changes at clangd code, ideally without changes?

what do you want to track precisely with that?

if it’s for figuring out whether clangd returned declaration as a transient error (e.g. indexing is incomplete) vs as a permanent state (e.g. definition is non-existent), i am not sure if we’ve enough information to tell apart those two at all times so this won’t be useful in all cases.

if it’s for tracking of what percentage of go-to-def requests or using the fallback, we’ve got some mechanisms in clangd to track metrics, we can introduce one here (unfortunately we don’t really have nice ways to expose these metrics, apart from a CSV based method ATM, but the interface is extensible so you can in theory plug it to some other time-series based database). but again i don’t think it’ll be as useful since we can’t tell apart transient/permanent failures for sure.

@kadircet , thank you for the reply. You are right and I am going to use it mostly for logging purposes. The primary goal is to catch some info about the transient errors (index is incomplete). Right now we have no way to get any info about it but the method should allow us to get some (probably incomplete) data. That should allow us to make some future decisions on the response data: should it be accepted or an alternative source (not clangd) should be used.