Length of inlay type hints exceed `inlayHints.maxLength`

[oakrotka]

rust-analyzer version: rust-analyzer 1 (9db05508ed 2025-08-11)

rustc version: rustc 1.88.0 (6b00bc388 2025-06-23)

editor or extension: NeoVim 0.11.3 from the arch linux repository, with the nvim-lspconfig plugin (latest git)

relevant settings: my rust analyzer neovim config:

vim.lsp.inlay_hint.enable(true)

vim.lsp.config('rust_analyzer', {
  settings = {
    ['rust-analyzer'] = {
      check = {
        command = "clippy",
      },
      cachePriming = {
        enable = false
      },
      inlayHints = {
        maxLength = 25,
        parameterHints = {
          enable = false
        },
      }
    }
  }
})

(probably the most important one is that I have inlayHints.maxLength explicitly set to 25, but that is also the default)

the problem

the inlayHints.maxLength option is documented as "Maximum length for inlay hints.". however, the displayed hints frequently exceed that amount. the following code

struct ThisIsALongStructName<T>(T);

fn main() {
    //   1   5    10   15   20   25   30   35   40   45  49
    let x = ThisIsALongStructName(ThisIsALongStructName(()));
}

with the earlier provided rust-analyzer settings turns into this:

the inlay hint ends up being 49 characters long, which is almost twice as long as the provided maximum.

looking at the code, it looks like the current logic is to expand everything going from the beggining until the character limit is exceeded, and only then to start truncating the following contents. this of course results in hints that are longer than the limit, which is against the documentation and intuition of what an inlayHints.maxLength option should do.

more reasonable behavior here would be to first compute the minimal length of the current type hint when its properties are not expanded, then it if it exceeds maxLength to truncate it, otherwise to expand its properties (probably breadth-first expansion would be best here)

(I'm not sure if it's also a problem with other inlay hints, I've only checked the behavior for type hints)

[ChayimFriedman2]

That's true, the implementation is heuristic and works the best when you have a type with multiple components (e.g. many generic parameters), not when there are long names.

I don't believe we can change that but the documentation should probably highlight that.