lh123 added a comment. In D72498#1816339 <https://reviews.llvm.org/D72498#1816339>, @sammccall wrote:
> 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. Currently, I think that in most cases, showing both expanded (canonical) and spelled types is sufficient. > This has been used in ycmd for ~4 years without complaint. > https://github.com/clangd/clangd/issues/58#issuecomment-507800970 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72498/new/ https://reviews.llvm.org/D72498 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
