Default argument heuristic for template parameters

[HighCommander4]

Clangd uses heuristics (implemented in the class HeuristicResolver) to try to resolve dependent names in templates to their declarations.

Currently, the main heuristic that's employed is assuming that a dependent template specialization will resolve to the primary template rather than to an explicit or partial specialization, which then allows us to heuristically resolve e.g. A<T>::foo (where T is dependent) by looking up foo in the scope of the primary template definition of A.

Another heuristic that's occurred to me recently is that if T is a template parameter, and it has a default argument, heuristic resolution could try to replce it with its default argument. So, e.g. if you're trying to resolve Allocator::pointer_type inside vector<T, Allocator>, currently we can't resolve that, but with this heuristic, if Allocator has the default arugment std::allocator<T>, we'd heuristically resolve it by replacing Allocator::pointer_type with std::allocator<T>::pointer_type (and then apply the existing heuristic to look up pointer_type in the primary template definition of std::allocator).

Thoughts? Does this heuristic seem useful / desirable?

[tom-anders]

This sounds really useful e.g. for dependency injection via templates:

class Implementation { 
   void foo();
 }

template <class Imp = Implementation>
class C {
   C(const Imp& imp) {
      imp.f^ // <- Would be cool if autocompletion would complete Imp::foo() here!
   }
}

[ops2abt]

This would be very useful! Is there any update if this will be implemented or if there is a workaround to still get suggestions in that use-case?

[HighCommander4]

I think this heuristic would be pretty simple to implement.

If anyone's interested in giving it a try, I'm happy to provide pointers to the relevant code and other guidance as needed.

[ops2abt]

Unfortunately, I don't really have the time and know-how to dive deep into the clangd code base, so you could see it as a feature request for know.

Maybe you could already write here a small abstract where the relevant code would need to be implemented and maybe some bullet points how you would address it / what the most important things are to consider there?

Then I or someone else might do it in the future :)

[HighCommander4]

As always, it's good to start with a test case. Here is a simple one:

struct Default {
  void foo();
};
template <typename T = Default>
void bar(T t) {
  t.foo();
}

With the heuristic in place, go-to-definition on the foo token in the function body of bar should take you to the declaration of Default::foo().

This test case can be added to the test LocateSymbol.All; you can look at the existing test cases there to see how to formulate it.

Note that we're testing go-to-definition because that's the main feature that uses HeuristicResolver at this time. Code completion does not yet use HeuristicResolver (though we have #810 on file for that, and that's something I'm hoping to pick up this year) and so won't currently be affected.

As for the fix, I imagine it going around here, and involving the following steps:

• check if T is a TemplateTypeParmType
• if so, get its associated TemplateTypeParmDecl
  • (note the caveat mentioned in this comment: the decl needs to be queried before unwrapping the type to its canonical type)
• check if the TemplateTypeParmDecl has a default argument
• if so, replace T with the type of the default argument

We can imagine making the heuristic a bit smarter (e.g. handling the case where the default argument ends up itself being a template parameter of another type, and applying the heuristic recursively in that case), but that can be left for a follow-up. What I outlined above should be sufficient to get the test case I wrote working.

[ops2abt]

Yes, it would be very useful. Actually, we just switched from IntelliSense to Clangd and would not switch back due to many great features that clangd provides. But this feature is really missing for us in clangd. We also use inl files to make the implementation separate from the template definition and then you have to jump to another file to find the place where you can jump to the Implementation...

What we currently do as workaround is, that we change the template in the inl file to <class Implementation> and then you get the right suggestions. Then when we are finished with programming we switch it back to <class Imp = Implementation>.

So this feature would really benefit us!