Incoming call's hierarchy item's range is not usable as a point from which to start a new call hierarchy

[bstaletic]

I am not sure if this should be a bug report or a feature request.
I have implemented call hierarchies in my client and only rust-analyzer is behaving counter to my expectations.

fn f() -> i32 {
    5
}

fn g() -> i32 {
    f() + f()
}

fn h() -> i32 {
    let x = g();
    f() + x
}

With the above file, here's what I am trying to achieve:

1. Get incoming calls from g() on line 4, column 3. (lines and colums are 0-based)
2. The response is as expected - a single item, saying thaat the call to g() is on line 9, column 12, coming from function h().
3. Now I would like the ability to go in the opposite direction, by only looking at the previous response.
4. With other servers, that is achievable, because call_hierarchy_item.range covers h, but with rust-analyzer, the range is the whole function. That means that using call_hierarchy_item.range.start for the next textDocument/prepareCallHierachy request returns an empty response.

Here's a link to asciinema showing how this works in the editor, with gopls server:
https://asciinema.org/a/NJRympD1YW7NvrHl9rT8uWCc7

Currently, this is what happens when I try to do the same with rust-analyzer:
https://asciinema.org/a/5vElc3tQ8q7UW2nW5QkP7stAJ

I have also attached rust-analyzer and ycmd log files.

Ideally, rust-analyzer would return a range that could be used for a susequent prepare hierarchy request.
If that is considereda breaking change, maybe a new config option would be doable?
Failing that, a custom extension to the call hierarchies? I wouldn't be thrilled about a server-specific behaviour, but crrently my only option is to prevent users from trying to "switch hierarchy direction" if they are in a rust file.

rust-analyzer version: rust-analyzer 1.81.0-nightly (a70b2ae 2024-06-09)

rustc version: rustc 1.81.0-nightly (a70b2ae57 2024-06-09)

editor or extension: Vim/YouCompleteMe

relevant settings: no settings were changed from the defaults

repository link (if public, optional): ycm-core/ycmd#1733

[Veykril]

The lsp docs on the range property do state

	/**
	 * The range enclosing this symbol not including leading/trailing whitespace
	 * but everything else, e.g. comments and code.
	 */

which implies to me that we are doing everything correctly here. Notably though, there is the selectionRange property which we do point to just the function name, and given its documentation

	/**
	 * The range that should be selected and revealed when this symbol is being
	 * picked, e.g. the name of a function. Must be contained by the
	 * [`range`](#CallHierarchyItem.range).
	 */

it feels like this is what you ought to be using here for this kind of logic instead?

[bstaletic]

I have definitely overlooked selectionRange.
Looks like selectionRange is what I need. Thanks!

For what it's worth, here's what happened with different servers:

• clangd has the selectionRange data in selectionRange and in range.
• gopls behaves the same as clangd.
• jdt.ls correctly differentiates between the two ranges, but can start a call hierarchy from range.start.
• rust-analyzer differentiates between the two ranges but can not start a call hierarchy from range.start.

[Veykril]

jdt.ls I imagine they allow the feature to be invoked from anywhere within the function signature where as we require the cursor on the function name