LGTM! My bad, thanks for fixing this

Let me backtrack my previous question: I misremembered where AddChild is actually being called in the traversal (ASTNodeTraverser, not TextNodeDumper), so I'll see if adding this to the JSON output is feasible

I incorporated the cast, ASTContext and StringRef suggestions. About JSONDumper, I was surprised to see that it doesn't seem to use AddChild for the AST hierarchy at all, so I'm not quite clear how (if?) it builds a nested output. What's the easiest way to invoke it?

Not sure I qualify as a suitable reviewer, but this looks really good to me, save for maybe a small safety measure :)

Your approach to handling implicit conversions is much nicer than mine, so I abandoned my revision. There is still one case (that might even occur in the code base I'm working on?) that this change would lead to incorrect hints on. WDYT about keeping the other changes, but using my pack detection logic?

Superseded by https://reviews.llvm.org/D130260

@nridge @sammccall if you don't have any further comments, I will commit this tomorrow, and maybe think about how to extend it to signature help/code completion :)

don't add reference hints to unresolved parameter packs

detect whether forwarding functions preserve reference-ness and value categories of their arguments

yes, I have commit access

• simplify parameter pack detection
• improve function naming
• make handling of unexpanded packs and varargs more visible
• add tests involving template specializations
• make documentation more descriptive

can you give this another look, if you have some time @sammccall?

• remove inlay hints from std::forward in tests
• identify recursive variadic calls from template, not post-processing
• allow template parameter packs to appear at any place
• improve documentation

• improve documentation
• add more edge case tests
• fix reference hints for parameter packs
• remove unnecessary headers
• fix bug in handling of tail parameters

@nridge @sammccall can you give this another look?

add test for varargs function called from forwarding function

This is now ready to review, only needed to fix a formatting issue

• fix varargs, again :)
• remove parameter names entirely if they occur multiple times

Thanks Nathan, that was exactly it. I thought I looked at getTypePtr() directly, but I must have been mistaken.
After a small fix (only adding inlay hints until the first unexpanded pack expression, it seems to work now).

Of course, I forgot to create a new diff. There is some debug output and logic errors for some of the tests, but the simple ones already show the issue.
The function in question is getPackTemplateParameter, which provides similar functionality to isExpandedParameter before

I've hit a roadblock I'm not sure how to proceed with. It seems that in some cases, a ParmVarDecl of an instantiated function template indeed doesn't preserve the SubstTemplateTypeParmType type sugar allowing me to check which template parameter it was instantiated from. This might be related to reference collapsing on type deduction, since Args... preserves the sugar, but Args&&... doesn't. Without this ability to distinguish between expanded packs and normal parameters, I risk recursing into other functions and pulling up unrelated type names. Any ideas how to proceed here? Essentially, it's the same issue that @nridge already provided a partial solution for by not using getNonReferenceType(), but more complex. I would really like to avoid having to reconstruct parameter indices from arbitrarily many levels of template parameters packs from surrounding scopes.

Yes, I think that's a good summary. Only a small clarification:

I will update this to split up the control flow into a visitor just collecting a single recursion level and the high-level mapping. A general question here would be whether we should do the resolution by parameter or by parameter pack. Doing it by parameter (like I did it right now) is much easier for inlay hints, especially if the pack gets split up into different parts, but that may not necessarily be the case for template functions and more fuzzy cases like signature help/autocomplete.

@sammccall Feel free to merge with Author: Tobias Ribizel <ribizel@kit.edu>
Thanks for the vote of confidence, I'll apply once the forwarding stuff is done :)

review updates

remove std::forward bodies from diagnostic tests

@sammccall @nridge can you give this another look? :)

It seems like except for the caveats I listed before, all the obvious cases seem to work: make_unique, make_shared, emplace_back with exact type matches. One point that still needs some work is if the parameter needs to be converted inside one of the forwarding functions (probably just needs another unpack inside ForwardingParameterVisitor), as well as a way to remove duplicate parameters that come from recursive templates like std::tuple. One obvious way would be removing inlay hints for duplicate parameters altogether, but that may not be enough/too heuristic? Alternatively, we could inspect the template instantiation pattern.

attempt to fix the patch issue

• add test for emplace-like functions
• fix RecursiveASTVisitor early exit
• fix handling of skipped parameters

update test docs

review updates:

fix iterator invalidation issue, handle UnresolvedLookupExpr and test recursive and split variadic lookup

updated patch baseline

accidentally pushed to the wrong revision, this is the previous version

Work around the currently broken isExpandedParameter, also fix the broken diff

Work around the currently broken isExpandedParameter, also fix the broken diff

This almost works now, the only thing that needs to be fixed is isExpandedParameter, which for some reason picks up the first call, but not the second: (Compare ParameterHints.Forwarded and ParameterHints.VariadicPlain)

cpp
void foo(int a);
    template <typename... Args>
    void bar(Args&&... args) { return foo(args...); }
    void baz() {
      int b;
      bar(42); // This parameter is recognized as expanded
      bar(b); // This one doesn't, so its inlay hint is @args: instead of a:
    }

use an RecursiveASTVisitor instead of ASTMatcher

! In D124690#3493246, @sammccall wrote:

This makes sense to me.
This sounds more complicated, but if I'm reading correctly this multi-level forwarding isn't handled in the current version of the patch either?
At some point we'll want to extract this logic out so it can be used by hover etc, but not yet.

I will take a different approach to the matchers: For each CallExpr involving parameter packs, record the arguments (if they are a ParmVarDecl or stdForward(ParmVarDecl)) and the matching ParmVarDecl of the FunctionDecl in a map. Then I will compact that map to skip intermediate forwarding functions like emplace_back -> allocator::construct -> constructor and in a second pass resolve all previously unresolved forwarded parameters.

I don't have commit access to LLVM, so feel free to merge it

move standalone-specific code to LLDBStandalone.cmake

fix standalone builds

Rewrote detection of forwarding functions in preamble, added --preamble-parse-forwarding flag

remove unnecessary annotation

add test for const ref inlay hint via type alias

right, arcanist doesn't entirely match my git mental model. Here's the (hopefully) complete patch

Thanks, on second thought moving the hint to the prefix also makes more sense to me.

address review comments: Move reference hint to the prefix, test type aliases

I think we should be able to do this without adding new matchers globally.

don't add reference inlay hints for r-value refs

Thanks for checking! Putting it behind a flag was my intention from the start anyways, since ideally I would like to traverse the AST through something like emplace_back ->construct/realloc_insert -> allocator::construct until I reach a non-forwarding function.
Do you have some pointers on what needs to be done to add a new flag? I am still kind of new to LLVM development :)

restore some of the previous behavior

improve handling of disabled libedit

revert remaining unnecessary change from initial diff

fix broken build without libedit, improve find module

The previous setup didn't work for clang-query, so I added a CMake IMPORTED target for LibEdit and used it everywhere

I wasn't aware of that, sounds perfect, thanks! Then I'll put this on hold until I figure out if it's really necessary.

This is part of my long-term goal to add support for forwarding parameters and documentation for make_unique-like functions to clangd. To be fair, the details are not entirely fleshed out - for inlay hints (displaying parameter names inline), the entire function template is already available in an instantiated form, so I can work with existing matchers. For signature help (displaying which parameters are available, which one is active while typing), IIRC you only have the template instantiation pattern available, so I need to find the necessary parts of the AST myself.

formatting

add tests for reference inlay hints

@nridge Please do, I don't have commit permissions :)

• use string literal for toString result

push full patch

Review updates

• format

forgot to include the old changes in the diff