Summary: | [compiler] Regression bug against Eclipse 3.3: cannot resolve correct import | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Mauro Molinari <mauromol> | ||||||||||||||
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> | ||||||||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||||||||
Severity: | critical | ||||||||||||||||
Priority: | P3 | CC: | daniel_megert, jerome_lanneluc, kent_johnson, konigsberg, Konstantin.Scheglov, Olivier_Thomann, philippe_mulet, tom.schindl | ||||||||||||||
Version: | 3.4 | ||||||||||||||||
Target Milestone: | 3.4.1 | ||||||||||||||||
Hardware: | PC | ||||||||||||||||
OS: | Windows XP | ||||||||||||||||
Whiteboard: | |||||||||||||||||
Attachments: |
|
Description
Mauro Molinari
2008-07-02 08:08:38 EDT
If truly a regression, then we should address it for 3.4.1 Created attachment 106408 [details]
Project that exhibits the problem
I was able to prepare a tiny testcase that shows the problem and I was able to identify the problem. Please see my next comment.
First of all, prepare a new empty workspace. Set it up so that you have a 1.6 JRE bounded to JSE 1.6 Execution environment. Then, unzip the folder "Test bug 239229" in the attached ZIP into your new workspace and import the project in that folder. Now, have a look at the code: - com.ost.util.report.FilterConstraintSpecification does not compile because it can't resolve the package com.ost.util.report.exceptions... but that package is there! - the same for com.ost.util.report.InspectedMatrix - com.ost.util.report.Matrix<T> and com.ost.util.report.MatrixInspector, instead, don't have problem to resolve that package. Now, take com.ost.util.report.FilterConstraintSpecification, remove the offending import line, press Ctrl+Shift+O, then save: you'll see that the error vanishes. Then, invoke Project | Clean... and clean the project: the error will appear again! This is weird and this is what I observed in my real problem. But now the funny part... Open com.ost.util.report.Matrix<T> and see the "@see" line in its Javadoc. First of all, notice that no warning nor error is given for that malformed @see clause (I obviously activated all the Javadoc validation options), although it is clearly wrong. But now, remove the line containing the "@see" tag and save. Then do a Project | Clean... TADAA! The error "The import com.ost.util.report.exceptions cannot be resolved" on both com.ost.util.report.FilterConstraintSpecification and com.ost.util.report.InspectedMatrix is vanished! Mauro. (In reply to comment #3) > This is weird and this is what I observed in my real problem. I meant: "in my real project"! Sorry for the typo. Mauro. Reproduced. Problem only occurs when enabling javadoc diagnoses, and after 3.4M6. The error indeed comes from the unbound reference in javadoc: /** * @see exceptions.InvalidRowSizeException */ I believe it is related to change for bug 196200. Added ProblemTypeAndMethodTest#test081 Simpler testcase: //p/X.java package p; public class X extends zork.Z { } //p/Y.java package p; import p.zork.Z; public class Y { } //p/zork/Z.java package p.zork; public class Z { } Created attachment 106735 [details]
Patch in progress (3.4)
The problem may occur outside javadoc. Only need a prior reference to missing type which is colliding with subpackage to cause some later confusion.
In particular, I am not yet satisfied with behavior of patch for ProblemTypeAndMethodTest#test081 producing unexpected error:
"3. ERROR in com\\ost\\util\\report\\Matrix.java (at line 9)\n" +
" throw new InvalidRowSizeException();\n" +
" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n" +
"No exception of type InvalidRowSizeException can be thrown; an exception type must be a subclass of Throwable\n"
Philippe - so this is a case of a MissingType taking precedence over a package that we have yet to find/request ? We've had similar issues with types that conflict with packages. Possibly we could handle this by searching for a conflicting package before adding a MissingType to a package's cache... then you wouldn't need to check everytime someone requests a package/type. Created attachment 106736 [details]
Simple check
My suggested patch is causing lots of regressions. I had thought of checking for conflicting package before adding missing type, but I was under impression this was weaker, as we may not know all packages at that stage (thinking of requested types to come in later). Created attachment 106796 [details]
Better patch for 3.4.x
Addresses the issues raised by previous patch.
Created attachment 106802 [details]
Better patch for 3.4.x take 3
Created attachment 106810 [details]
Proposed patch
for HEAD
Also added ProblemTypeAndMethodTest#test082-088 Released for 3.4.1 Released for 3.5M1. Fixed Verified for 3.5M1 using I20080805-1307 *** Bug 245304 has been marked as a duplicate of this bug. *** Verified for 3.4.1 using M20080827-2000 |