sammccall added a comment.

In https://reviews.llvm.org/D52308#1240642, @jkorous wrote:

> You might be right - I am assuming here that we want consistent behaviour 
> between constructors and destructors.
>
> IIUC ctors are currently skipped in code completions (in most cases) but they 
> also don't have any type associated while result of their call definitely has 
> some type.


Tricky.

**MyClass()** has a type, and should probably have return type MyClass, though 
it's pretty clear from the name (one could make the same argument about 
destructors).
Note that the "return type matches" ranking heuristics will trigger on these 
types so it's not just presentational, I think we should be including the types 
for constructors.

But class Derived : MyClass { Derived : **MyClass()** {} }; doesn't have a type 
(it's not an expression).

And MyClass::**MyClass()** has a type, but it's probably more likely that the 
user is going for a plain **MyClass::MyClass** (e.g. in a class-scoped using 
decl) which doesn't have a useful type.

> Currently we are showing destructors in code completion in clangd (with 
> detail "void") - that's actually how I noticed this.
> 
> I would assume that canonical type in function/method code completion is 
> "it's type" not "type of result of it's call". WDYT?

I don't think so, for better or worse it's result of it's call. Or rather: type 
of the expression that we guess the user's going to form, or that we suggest.
Again, this seems to give the best code completion presentation, and also best 
ranking results (when the expected type of the context is known)


Repository:
  rC Clang

https://reviews.llvm.org/D52308



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to