Currently, the LSP specification uses selectionRange in only three places:
In selectionRange requests
In hierarchy items
In DocumentSymbol
Since ycmd does not support the first and the third point, we can ignore them..
As for hierarchy items, range property is meant to span the entire symbol definition, while selectionRange property is meant to span just the identifier of a symbol. Note that range also can include a docstring preceeding a function definition. That means that symbol[ 'range' ][ 'start' ] might be pointing at the start of a docstring, instead of pointing at the function name.
Current behaviour of the tested servers:
clangd and gopls put what should be in selectionRange into both properties.
jdt.ls and rust-analyzer properly differentiate these two ranges.
Not handling selectionRange properly leads to at least two problems:
In hierarchy requests, the description of the root node can be wrong.
Requesting outgoing calls of an incoming call picks the wrong location altogether.
Currently, the LSP specification uses selectionRange in only three places:
selectionRange
requestsSince ycmd does not support the first and the third point, we can ignore them..
As for hierarchy items,
range
property is meant to span the entire symbol definition, whileselectionRange
property is meant to span just the identifier of a symbol. Note thatrange
also can include a docstring preceeding a function definition. That means thatsymbol[ 'range' ][ 'start' ]
might be pointing at the start of a docstring, instead of pointing at the function name.Current behaviour of the tested servers:
clangd
andgopls
put what should be inselectionRange
into both properties.jdt.ls
andrust-analyzer
properly differentiate these two ranges.Not handling
selectionRange
properly leads to at least two problems:This change is![Reviewable](https://reviewable.io/review_button.svg)