Rust Analyzer: Inlay hint fragments apply in reverse order

[listochkin]

Check for existing issues

• Completed

Describe the bug / provide steps to reproduce it

Rust Analyzer has optional hints for closure captures. When enabled Zed shows their fragments in reverse order.

Version: Zed 0.122.2 a1c5d027319bd80ae348fa3ce2be22c2a6785284

Steps to reproduce:

1. Adjust your editor settings:

"inlay_hints": {
  "enabled": true,
},
"lsp": {
  "rust-analyzer": {
    "initialization_options": {
      "inlayHints": {
        "closureCaptureHints": {
          "enable": true
        }
      }
    }
  }
}

2. Create a new Rust project cargo new inlay-hints-reverse-fragments, replace the code in main.rs with the following:

fn main() {
    let x = 42;
    std::thread::scope(|s| {
        s.spawn(|| {
            let _x = x;
        });
    });
}

Results:

(I put hints in comments to keep GitHub Syntax highlighter happy):

// Expected
std::thread::scope(/* move (&x) */|s| {

// Actual
std::thread::scope(/* &x) (move */|s| {

You can see how fragments of hints get applied in reverse order. Also, As I type code (just add spaces at the end) I sometimes see them flicker, extra parenthesis may show up or hide, etc. Seems like some inconsistencies during updates, but most likely an unrelated issue.

VSCode shows these hints correctly, as do unit tests in Rust Analyzer repo: https://github.com/rust-lang/rust-analyzer/blob/ac998a74b3c8ff4b81c3eeb9a18811d4cc76226d/crates/ide/src/inlay_hints/closure_captures.rs#L143

Environment

Zed: v0.122.2 (Zed)
OS: macOS 12.7.3
Memory: 32 GiB
Architecture: aarch64

If applicable, add mockups / screenshots to help explain present your vision of the feature

No response

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

If you only need the most recent lines, you can run the zed: open log command palette action to see the last 1000.

No response

[SomeoneToIgnore]

Relevant LSP response part:

[
        {
            "position": {
                "line": 73,
                "character": 16
            },
            "label": "move",
            "paddingLeft": false,
            "paddingRight": false
        },
        {
            "position": {
                "line": 73,
                "character": 16
            },
            "label": "(",
            "paddingLeft": false,
            "paddingRight": false
        },
        {
            "position": {
                "line": 73,
                "character": 16
            },
            "label": [
                {
                    "value": "&x"
                }
            ],
            "paddingLeft": false,
            "paddingRight": false,
            "data": {
                "file_id": 0
            }
        },
        {
            "position": {
                "line": 73,
                "character": 16
            },
            "label": ")",
            "paddingLeft": false,
            "paddingRight": true
        },
    ]

looks like all those hints belong to a single point in the real text, and Zed mixes them up during display.
It's hard to say without extra debugging, where does the issue come from, but instant suspicious place would be

zed/crates/editor/src/display_map/inlay_map.rs

Lines 507 to 515 in e9f400a

	let start_ix = match self.inlays.binary_search_by(|probe| {
	probe
	.position
	.to_offset(&buffer_snapshot)
	.cmp(&buffer_edit.new.start)
	.then(std::cmp::Ordering::Greater)
	}) {
	Ok(ix) | Err(ix) => ix,
	};

[xvbcfj]

would be good if this gets fixed soon