ilya-biryukov added a comment. In D72498#1816424 <https://reviews.llvm.org/D72498#1816424>, @lh123 wrote:
> 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 That actually doesn't look bad. Maybe let's try doing that and see whether we'll get negative feedback? That seems to give useful information in **all** cases, so at least it'll cover all use-cases even it's more verbose. What do others think? In D72498#1816668 <https://reviews.llvm.org/D72498#1816668>, @kadircet wrote: > In D72498#1813989 <https://reviews.llvm.org/D72498#1813989>, @ilya-biryukov > wrote: > > > In D72498#1813962 <https://reviews.llvm.org/D72498#1813962>, @sammccall > > wrote: > > > > > > > > > > > I tend to disagree here. decltype is normally the last resort, so whatever > > it produces is probably super-obscure, would even expect it to be not > > representable in C++ in many cases. > > > I was rather talking about the obscurity of the expression inside decltype vs > the typedef alias. I believe it is a lot harder to make any assumptions on > `decltype(callback)` compared to `IntMap` without seeing the underlying type. Point taken, although I bet we could come up with examples of obscure results in both cases. >> Would definitely be helpful. If you feel we have some room in hover, I would >> love to have that. But there's a balance to be made, see Sam's comments >> about canonical types being obscure. I agree on 50% of the cases :-) > > I think this should be OK to spend some space, as it will only show up when > needed. I believe `better` printing of canonical types is a different problem > we should definitely solve. Totally agree, improving printing of STL types would be huge, no matter whether they're canonical or not. 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
