Community
Participate
Working Groups
build i0222 - start Eclipse with an empty workspace - switch to the Java perspective - Open Type... - nothing is in the list - Window -> Show View -> Other -> PDE -> Plug-ins - org.eclipse.core.resources - use context menu to Add to Java Search - OK - Open Type... - choose "Workspace" class - pick a method, any method - double-click to add a breakpoint Note that: - the break point appears and then immediately disappears - break point is moved to be the last line (closing brace) of the method When setting a breakpoint in the breakpoint location validator, it was determined from the AST that the super-class (PlatformObject) could not be resolved so that's why the breakpoint was moved. Is it necessary to have to resolve the class in order to set a breakpoint?
If the code needs to be resolved, the proper context should be provided. Otherwise it is likely that the resolution will fail.
See also bug 86542.
Resolving the class is not required to set a breakpoint, but is usefull for one specific case. With some code : 1: int i= 2 2: + 3; if you try to add a breakpoint line 2, the breakpoint will be move line 1, because we know the compiler doesn't generate code for line 2, the constant value is resolve at compile time. We are currently doing this optimisation if we think the compiler will be able to resolve the bindings. The current implementation is, if we have a Java project, we can ask and will get the bindings. It's obviously wrong in this case (and others). But, that shouldn't be a real problem, we can check if bindings were resolved after the fact. The real problem is the fact that the compiler doesn't return the complete AST of the type in this case, the method nodes are empty. It looks like because we asked for the bindings to be resolved and the superclass is not available, the compiler does not complete the parsing. I would have excepted to get the complete AST, with no bindings. Olivier, is this the normal behavior (incomplete AST if problems with the bindings) ? I don't see anything in javadoc about it.
This looks like a bug. When the hierarchy cannot be built, the compilation aborts. At this moment the methods inside the compilation unit have no body. I take the bug back and I will investigate a fix.
Luc, You found a bug in the AST. When the bindings cannot be resolved, we should not abort and give a complete tree. However you should not request the bindings just to support the case you describe. Requesting the bindings cost in memory and speed. It would be must faster to create the tree without the bindings. So I suggest that you set up the creation of the tree without the bindings. We will fix this issue in our code.
Fix is released for JDT/Core. Regression test added. You should still investigate the necessity to get bindings in this case. I don't believe you should resolve the bindings.
Fixed in BreakpointLocationVerifierJob and ValidBreakpointLocationLocator. Modified the job to run first without bindings, and determine if bindings would have been helpful. If so, and binding info is available (i.e. we hava a Java model context), the job is re-run with bindings.
Please verify, Luc. Luc, I have one question about the code in ValidBreakpointLocationLocator#visit (Assignemnt). It only checks the right hand side of the assignment if the left hand side is a local or a static fields. Why does it exclude non-static fields?
Verified. For your question, the test case is (bug 75599) : 1: 2: foo 3: = 4: <expression>; if the user ask to set a breakpoint on line 1 and 'foo' is a local variable or a static field, the breakpoint is set on line 4. The idea is, when the user ask to set a breakpoint on a empty line before the assigment, he wants the vm/thread to suspend on the first intruction to be executed after line 1. If 'foo' is a local variable or a static field, the code generated by the compiler is something like: - code for <expression> - store result in 'foo' The expression is executed first if 'foo' is an non-static field, the generated code is looks like: - push 'this' on the stack - code for <expression> - store result in this.foo The first instruction is the push of 'this', this instruction is associated with the line of the 'foo' identifier. If the user ask for a breakpoint on line 2, it is set on line 2.
