Code Assist on Method Calls - How to get the target variable? [message #259124] |
Thu, 19 March 2009 08:06  |
Eclipse User |
|
|
|
Hi,
I'm trying to filter method call proposals of the JDT code completion
based on several critieria. For this filtering I need access to the local
variable (name and type) for which the code completion has been triggered.
However, it seems to me that there is no straight forward way to get
access to this information. Am I right? Currently, I resolve the ASTNode
at the current cursor position using the internal NodeFinder API and try
to resolve the target variable by visting the neighboring ASTNodes
manually. This is not working in all cases and I'm now asking for a better
way how to get the reference to the local variable type *and* name.
My current code to determine the target variable of a method completion
request looks as follows:
final ICompilationUnit cu = context.getCompilationUnit();
final int offset = context.getInvocationOffset();
final CompilationUnit ast = ASTResolving.createQuickFixAST(cu, null);
final char[] token = context.getCoreContext().getToken();
ASTNode n = NodeFinder.perform(ast, offset - token.length, token.length);
String varName = null;
Itype varType = null;
outer: while (n != null)
{
switch (n.getNodeType())
{
case ASTNode.BLOCK:
[...]
// case statements for all relevant ASTNode types
// which might help to resolve varName & varType.
[...]
// end of while:
if (var.name != null)
{
break;// while
}
n = n.getParent();
} // do it again with the parent node until
//we are able to resolve the variable
Summarized, is there a better solution to get values for
"String varName" & "IType varType" ?
Thanks and all the best,
Marcel
|
|
|
|
|
Re: Code Assist on Method Calls - How to get the target variable? [message #259182 is a reply to message #259170] |
Sun, 22 March 2009 16:38   |
Eclipse User |
|
|
|
Originally posted by: alamothe.ptt.yu
Hi,
I noticed that java completion proposals obtain the AST this way:
private CompilationUnit getASTRoot(ICompilationUnit compilationUnit) {
return SharedASTProvider.getAST(compilationUnit, SharedASTProvider.WAIT_NO,
new NullProgressMonitor());
}
Perhaps this is faster than your original approach
Marcel Bruch wrote:
> Hi Daniel,
>
> Daniel Megert wrote:
>> Note that code completion has to be fast. Creating an AST for that is
>> not a good idea.
>
> Thanks for your reply. I'm aware of performance issues. Currently, our
> proposal engine needs 0.1 up to 0.2 seconds. However, the tool we are
> developing is a prototype for a novel Eclipse code assist system that
> filters method calls that are irrelevant for a given local variable.
> Wether or not a proposal is irrelevant is decided based on some
> context information like method calls previously invoked on this
> local variable etc. Thus, I need access to the local variable
> somehow... (unfortunately).
> If you want to know little more about the project and the idea behind
> this post, please visit http://www.stg.tu-darmstadt.de/research/core/
> and install the current prototype from the Eclipse update site
> available under
> http://cage.st.informatik.tu-darmstadt.de/frameworks/core/. If you
> are interested in some performance numbers how well the system can
> filter irrelevant method calls at the moment, drop me a line. I can
> provide some statistics for the current alpha version of the Eclipse
> code recommender.
> Anyway, my question remains. Is there a way to obtain the required
> information w/o reducing the performance too much with some internal
> Eclipse API? Thank you again for your help.
>
> All the best,
> Marcel
|
|
|
|
|
Re: Code Assist on Method Calls - How to get the target variable? [message #259259 is a reply to message #259207] |
Fri, 27 March 2009 05:29  |
Eclipse User |
|
|
|
Got things running. To close this thread:
org.eclipse.jdt.internal.codeassist.CompletionEngine &
org.eclipse.jdt.internal.codeassist.complete.CompletionParse r
solved my problem. The CompletionParser gives you a special ASTNode (in
field AssistParser.assistNode) which contains all required information
(var name, type, completion context etc.).
It's fast, it's reliable, it's fine - it's internal :( We will see
whether or not this internal dependency will cause problems in 3.5. Maybe
it is an option to make this part of an public API? By providing something
like an "Proposal Participant" Extension point? However, I'm fine with
this solution right now.
Thanks for the discussion and all the best,
Marcel
Nikola Mihajlovic wrote:
> You can start looking from ICompilationUnit.codeComplete(...) to see how
> eclipse computes core proposals, but I guess it's one enormous class which
> handles every case imaginable :-)
|
|
|
Powered by
FUDForum. Page generated in 0.15183 seconds