This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Support type hints for `decltype(expr)`
ClosedPublic

Authored by v1nh1shungry on Nov 18 2022, 7:46 AM.

Diff Detail

Event Timeline

v1nh1shungry created this revision.Nov 18 2022, 7:46 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 18 2022, 7:46 AM
v1nh1shungry requested review of this revision.Nov 18 2022, 7:46 AM
Trass3r added inline comments.
clang-tools-extra/clangd/InlayHints.cpp
321

Should use dyn_cast instead of is+cast I think.

Apply the comment's suggestion

v1nh1shungry marked an inline comment as done.Nov 18 2022, 8:15 AM

@Trass3r Thank you for the suggestion!

Avoid type hints for dependent types

  • fix qualifiers
  • fix recursive decltype (partly)
  • support return type
v1nh1shungry retitled this revision from [clangd] Support type hints for `decltype(expr)` in variable declarations to [clangd] Support type hints for `decltype(expr)`.Nov 19 2022, 10:25 AM
v1nh1shungry abandoned this revision.Dec 10 2022, 8:28 AM

Sorry for being a slow reviewer.

I think showing type hints for decltype(expr) would be a nice enhancement. @v1nh1shungry, are you interested in working further on this?

One high-level thought I had is: what if we attached the type hint to the closing ) of the decltype (and had it pertain only to the decltype(expr), not anything surrounding it like const or &)? It seems to me that this would both simplify the implementation, and allow us to show hints in places where decltype is used in a context unrelated to a variable or function declaration (for example, in something like using Foo = A<B<decltype(expr), C>, D>, if decltype(expr) was int, we would show using Foo = A<B<decltype(expr) : int, C>, D>. What do you think about this approach?

Thanks for the feedback!

One high-level thought I had is: what if we attached the type hint to the closing ) of the decltype (and had it pertain only to the decltype(expr), not anything surrounding it like const or &)? It seems to me that this would both simplify the implementation, and allow us to show hints in places where decltype is used in a context unrelated to a variable or function declaration (for example, in something like using Foo = A<B<decltype(expr), C>, D>, if decltype(expr) was int, we would show using Foo = A<B<decltype(expr) : int, C>, D>. What do you think about this approach?

I think this approach is better.

I think showing type hints for decltype(expr) would be a nice enhancement. @v1nh1shungry, are you interested in working further on this?

Sure!

clang-tools-extra/clangd/unittests/InlayHintTests.cpp
1155

The only concern I have is how to deal with this situation.

When I wrote this patch I thought maybe I could remove the & and figure out the underlying type of decltype(0) recursively and then add the & back. But at that time I couldn't find a way to get the referenced type or the pointee type.

nridge added inline comments.Dec 16 2022, 7:19 PM
clang-tools-extra/clangd/unittests/InlayHintTests.cpp
1155

This is a problem we already have for auto. For example, if you write:

auto i = decltype(0)();

the type hint for the auto is decltype(0).

The reason is that we are printing the type with TypeHintPolicy, which has PrintCanonicalTypes=false (the default). This means the type is printed without "type sugar" (e.g. decltype, typedefs) being replaced with their "underlying type".

We could alternatively print it with PrintCanonicalTypes=true, which would make the hint given in this case better, but it would make other cases worse (e.g. replacing std::string with std::basic_string<...>).

For the purposes of this patch, I think it's fine to just live with whatever type is printed with the current printing policy.

If we want to make improvements in this area, we can do that in a separate patch, and in a way that affects both auto and decltype(expr).

v1nh1shungry reclaimed this revision.Dec 16 2022, 7:22 PM

Got it! Thank you for the detailed explanation!

reimplement and address review's suggestions

nridge accepted this revision.Dec 19 2022, 12:34 AM

Thanks!

This revision is now accepted and ready to land.Dec 19 2022, 12:34 AM

@nridge Thank you for reviewing!

If this patch is ready to land, could you please help me commit it? Thanks again!

This revision was automatically updated to reflect the committed changes.

Done, thanks for the patch!