[PATCH] D72498: [clangd] Print underlying type for decltypes in hover

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D72498#1816244 <https://reviews.llvm.org/D72498#1816244>, @ilya-biryukov wrote:

> In D72498#1815500 <https://reviews.llvm.org/D72498#1815500>, @lh123 wrote:
>
> > - hover over the `front` , you'll see "instance-method `front` → `std::vector<int, class std::allocator<int> >::reference`".
> > - hover over the `push_back`, you'll see "`std::vector<int, class std::allocator<int> >::value_type && __x`".
>
>
> These look terrible and are the great examples where showing canonical types results in better output than canonical types.
>  I wonder why we add `std::vector<int, class std::allocator<int>>::` in the first place, I believe the standard library uses `value_type` in the declaration. Showing `value_type` is not great, but at least that doesn't uglify what was written in the code in the first place.
>  FWIW, I think the perfect output in those cases would be `int (aka value_type)`


Indeed. Another illustrative example, the return type of `vector<int64_t>::at()` - we'd probably want `int64&` here, rather than `vector<...>::reference` or `unsigned long long`/`unsigned long` depending on platform.

It seems like:

- unwrapping nothing isn't ideal
- unwrapping everything isn't ideal
- brevity might be a good heuristic, but unclear
- there's value sometimes in showing multiple forms, unclear exactly when

(Machine learning time? Mostly joking...)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72498/new/

https://reviews.llvm.org/D72498