Home » Language IDEs » Java Development Tools (JDT) » Unable to see problems associated with an ASTNode when copying it to a new AST
| Unable to see problems associated with an ASTNode when copying it to a new AST [message #256972] |
Fri, 17 October 2008 11:13  |
Eclipse User |
|
|
|
Originally posted by: myawn.ebay.com
I'm trying to provide a capability within our product to copy various
nodes from one Java file to another.
In the first piece I'm trying to implement, the node I'm trying to copy
is a MethodDeclaration.
I've parsed the 'source' file, identified the node to be moved, and used
ASTNode.copySubtree() to attach a copy of the MethodDeclaration into the
'target' source file.
What I need to do now is see if the node compiles cleanly in the new
location. Ideally, I'd like to be able to do the following:
- report via the GUI if the node is clean in the new location
- report via the GUI if the node has compile errors in the new location
- if the node has compile errors that are due to referencing types that
are not imported in the target file, offer an 'organize imports'-type
functionality that will add the required imports.
What I'm finding in all cases is that the node reports "clean", even
when it clearly would not compile cleanly in the new location. I'm
hoping someone will point me to the correct way to do this.
Steps I've tried so far:
- Initially I was parsing the node to be moved independently of any
compilation unit, e.g.,
ASTParser parser = ASTParser.newParser(AST.JLS3);
parser.setKind(ASTParser.K_CLASS_BODY_DECLARATIONS);
parser.setSource(methodSource.toCharArray());
parser.setResolveBindings(true);
ASTNode result = parser.createAST(null);
I always got back a "TypeDeclaration" result, as expected; never a
CompilationUnit result that I think would have been the result if the
parser had errors. (Not sure if that's true for all errors, or only
errors that are too severe for the parser to complete successfully).
- But that would never show me problems related to imports, so then I
began attaching the MethodDeclaration to the target AST, and trying to
get compilation results for the target AST as a whole.
- getFlags() on the MethodDeclaration node shows 2 (ORIGINAL) in the
source AST, and 0 (no flags set) in the target AST. I would expect
'MALFORMED' or 'RECOVERED' in case of errors.
- ICompilationUnit.getProblems() on the compilation unit of the AST
always returns an empty array
- Thinking maybe I would not see errors until a build, I performed an
incremental build on the IProject, but even after this I see an empty
list back from the getProblems() call.
Several points I'm not sure about:
- To see errors, is it sufficient to attach the method declaration to
the AST (copySubtree), or does it have to be inserted into the
bodyDeclarations as well? (I've tried both ways)
- Should getFlags() show me the error state of the method, or do I need
to use the ICompilation.getErrors(), or something else (I've tried the
first two)
- Is a build required to see the problems (have tried that)
- And most important, what it is that I haven't tried yet that is really
the reason this isn't working?
If it helps, there are really only two types of errors that I want to be
able to handle:
- MethodDeclaration return type or parameter types may be SimpleTypes
that require an import to resolve properly
- MethodInvocations within the method body might refer to methods that
no longer exist because of transformations we have made. When this is
true, we want to avoid copying this method to the target, so this is the
condition I'm most concerned about being able to catch.
Thanks,
Mike
|
|
| | |
| Re: Unable to see problems associated with an ASTNode when copying it to a new AST [message #256992 is a reply to message #256980] |
Mon, 20 October 2008 13:23  |
| Eclipse User |
|
|
|
Originally posted by: myawn.ebay.com
Mike Yawn wrote:
> Olivier Thomann wrote:
>> Mike Yawn a écrit :
>>> What I need to do now is see if the node compiles cleanly in the new
>>> location. Ideally, I'd like to be able to do the following:
>>> - report via the GUI if the node is clean in the new location
>>> - report via the GUI if the node has compile errors in the new location
>>> - if the node has compile errors that are due to referencing types
>>> that are not imported in the target file, offer an 'organize
>>> imports'-type functionality that will add the required imports.
>> Once you moved the node to the new unit, if you are using working
>> copies for the two units (the one where the method is originating and
>> the one where the method is moved), you could try to do a reconcile
>> operation on both units.
>> If you provide a problem requestor in the working copy owner that you
>> use to create the working copies of your actual units, you should be
>> able to get the "new" problems found once the code is modified before
>> you actually make the modification on disk.
>>
>> HTH,
>> --
>> Olivier
>
> I'll give that a try, thanks ...
>
> Mike
I must be missing something about proper use of working copies and/or
problem requestors.
- I created a WorkingCopyOwner that extends WorkingCopyOwner, but adds
no additional implementation. I think this is sufficient.
- I call ICompilationUnit.getWorkingCopy(owner, this, new
NullProgressMonitor()) to create a working copy and register my calling
class as the IProblemRequestor for the working copy.
- I parse the newly created working copy to get an AST.
- I copy the MethodDeclaration node of interest from the original AST
into the new AST of the working copy.
- I alter the MethodDeclaration node, getting the statements and
removing a variable declaration so that the node will not compile
cleanly (just for testing purposes)
- I'm not sure whether this part is required or not, but I add the
copied node into the bodyDeclarations() of the targeted AST. (I know
this would be necessary if we decided to keep the node, just not sure if
it's necessary for the problem reporting)
- I then call workingCopyCompilationUnit.reconcile(). I turned on
forceProblemDetection when there was no report of issues with it turned
off, but even with it on I see no issues.
I know that my problem requestor is in the loop, because I see calls to
isActive (where I return true), beginReporting, and endReporting. But I
see no calls to acceptProblem, even though I've created an obvious
compilation issue in the working copy compilation unit.
Mike
|
|
|
Goto Forum:
Current Time: Fri May 09 23:30:23 EDT 2025
Powered by FUDForum. Page generated in 0.03102 seconds |
Home