Re: [cdt-dev] Parameter Guessing

[Nathan Ridge <zeratul976@xxxxxxxxxxx>]

> I was able to do a quick debugging today, and it seems that the reason we don't get a list of proposals is what you fixed in this patch: https://git.eclipse.org/r/#/c/74172/1/core/org.eclipse.cdt.ui/src/org/eclipse/cdt/internal/ui/text/contentassist/DOMCompletionProposalComputer.java
>
> I am not sure why, but it seems that this getparent() makes binding resolution not able to figure out the declared variables.
> Maybe Sergey can verify if this ever worked before or is it a regression on this API, as he did this last refactoring?

I'm not sure if this is a regression, but I can explain why this change makes a difference.

For a variable to be considered for a parameter hint, it has to be among the bindings found via findBindingsForContextAssist() in DOMCompletionProposalComputer.getDefinedElements(). findBindingsForContextAssist() performs a lookup starting from the name passed as the first argument. The starting scope of the lookup is determined by calling getContainingScope() on the name. getContainingScope() walks up the AST starting from the name.

The name that getDefinedElements() passes in is an artificial AST node that we create right there. Before my change, we set its parent to completionStatement.getParent(). completionStatement is usually the statement inside which we are trying to perform completion, and completionStatement.getParent() is usually the compound statement representing the body of the function we are inside. The function's local scope is considered to be inside the compound statement, so if the name is a direct child of the compound statement, getContainingScope() will not find the function's local scope, but return the enclosing scope instead. As a result, local variables in the function are not considered for the parameter hint.

Making the name be a child of the completionStatement instead results in the function's local scope being found correctly.

> I didn't take a look at the rest of the patches, but if this mentioned changes alone solves the problem, what does the other patches do?

The other patches fix the test suite to actually exercise the code, and make the resulting tests pass.

Regards,
Nate