Community
Participate
Working Groups
Version: 3.2.0 Build id: I20051102-1600 I'm using ASTParser.createASTs to generate asts (with resolve bindings) for an array of 40 ICompilationUnits. When I get the callback to acceptAST from CompilationUnitResolver.resolve for the last CU in the array and I look at the caller I see that 40 (i= 39) CUs have been processed from about 200 (totalUnits= 193). The remaining units are processed after the last call to acceptAST meaning that a lot of work is done after I got all ASTs for my CUs. I don't know why this work is done. Is this work really required? Is this a bug maybe related to bug 111822 ? Or do I have to set a specific parser setting to prevent this behaviour (the code where I call createASTs is in org.eclipse.jdt.internal.corext.fix.CleanUpRefactoring#parse). This has a huge performance impact on the Clean Up source action.
I believe it is indeed a consequence of the fix for bug 111822. Now, you need this in order to exploit DOM ASTs, if not you may see partial binding information in presence of references to the downstream AST (if they wouldn't have been fully resolved). Offering a setting is something we could explore.
Philippe, what we don't understand is that fact that when the extra CUs are parsed when already processed ALL ASTs we requested.
And I guess this behavior as a negative impact in "Infer Type Arguments" as well (for which we don't have a performance test ;-)).
Changed CompilationUnitResolver#resolve(ICompilationUnit[], String[], ASTRequestor, ...) to stop processing units if all requested ASTs and all requested binding keys have been returned. Added regression test BatchASTCreationTests#test070().
Verified for 3.2 M4 using build I20051212-0010
