Bugzilla – Full Text Bug Listing
| Summary: | ASTParser resolves bindings without request | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> |
| Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | eclipsetalk2 |
| Version: | 3.2 | ||
| Target Milestone: | 3.2 M5 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
I just found that jdt.ui relies on this behavior in a few places. So we might get errors if you fix it right now. I'll make a pass and correct our errors today. Let me know when you are done. I've released the required changes in jdt.ui and tests to HEAD. From what I saw, jdt.debug should already be clean. Note: A reference search for setSource(char[]) showed that jdt.core also has a place where this assumption is taken. The javadoc of the deprecated AST.parseCompilationUnit(char[], String, IJavaProject) promises about what's currently implemented in ASTParser. Fixed and released in HEAD. Regression tests in org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2.test0625/0626 Verified for 3.2 M5 using build I20060215-0010. |
I20051130-1215 ASTParser resolves bindings without request when certain conditions hold, although setResolveBindings(true) has not been called. The following extract from internalCreateAST(IProgressMonitor) looks suspicios: if (this.rawSource != null) { needToResolveBindings = this.unitName != null && this.project != null && this.compilerOptions != null; ... I would not expect to get bindings unless I explicitly requested them. This can be a serious performance hit for clients that only need lightweight ASTs.