Community
Participate
Working Groups
Build 20040506 Using the attached test case (3 projects with one indirectly referencing binary missing on classpath), the editor is not showing the same errors during reconcile as the builder does.
Created attachment 10533 [details] 3 plugins testcase Here was a simple test case that I am running. 3 plugins: plugin3 defines SecretClass plugin2 references SecretClass (extends it, implements has the same problem) tested method reference - works, but highlights entire expression. tested field reference - works exactly as desired. plugin1 defines Main which references plugin2's class
There are 2 problems: - the build error is not correctly positionned on Dumbo reference. - the reconciler doesn't show the Dumbo problem. The offending reference is discovered too late for us to infer its proper location. It occurs during our referenced type recording process, where we walk superclasses... we don't know anymore what it corresponded to in the source. I tracked it down, and realized we are too lazy when we resolve bindings (for once). If reference recording is turned off, then we may accept code which javac would reject, since we never populate the supertype hierarchy for all types for which a member is accessed if we find the member locally to this type, e.g. field access, method access, constructor access, member type access. However, when we bookkeep references, we need to reach supertypes, and abort from there. I tweaked the reference recording for eagerly bookkeeping supertypes for these type of accesses, and proved getting the correct behavior then, but still it doesn't work when reference recording is turned off (e.g. when you are reconciling in editor, these errors do not show up, thus we are inconsistent in between build and edit time). We need to have an efficient way to cause faulting-in the supertypes of certain types (all these appearing as receiver types). If you provide me with the suitable API, I'll insert the call where appropriate.
I released some changes in Scope to fault in the hierarchy of receiver types.
When faulting in entire type hierarchies for member accesses, it works as expected: i.e. we abort at a point we are resolving a reference, and thus provide some useful source location in code. We may still want to improve a little bit the error location, since we denote the entire member access, where we could only blame its receiver portion.
Added regression tests: NegativeTest#test424-426. Fixed. Also entered bug 62070 for revisiting the reference recording post 3.0. I suspect we should actually be more lazy, and record less references. Need to investigate deeper. For now, consider this one fixed as we are now consistent in between editor and builder, plus we match javac behavior. I believe we can do a little better still if it doesn't break specs.
Verified in 200405180816
