Bugzilla – Full Text Bug Listing
| Summary: | [compiler] file location overrides package declaration during resolve | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Stephan Herrmann <stephan.herrmann> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jarthana |
| Version: | 4.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
(In reply to Stephan Herrmann from comment #0) > Internally I can see that the CUScope has the Default Package as its > fPackage, obviously because the file was found in the location of a default > package. > IMHO this is wrong. I think the package declaration should trump the > location where the file was found. that only explains, why we are searching the default package. On the target side of the type reference it's this line in SourceTypeConverter.convert(), that prefers the CU's parent over a declared package: String[] packageName = ((PackageFragment) cuHandle.getParent()).names; IMHO this is bogus, and we should instead use cuHandle.getPackageDeclarations(); This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. Stephan, I suppose you would want to keep this bug open? |
Test CompletionTests18.test435281() contains errors, which surprisingly don't bother that test. Minimal example: //-- src/C1.java -- package p1; public class C1 { } //-- src/C2.java -- package p2; public class C2 { C1 field; } //-- Although C1 & C2 declare to live in different packages and although C2 has no import whatsoever, the type 'C1' of 'field' is resolved with no complaint. Internally I can see that the CUScope has the Default Package as its fPackage, obviously because the file was found in the location of a default package. IMHO this is wrong. I think the package declaration should trump the location where the file was found. Be it only because mis-configured build paths are a much more frequent source of errors than wrong explicit package declarations. At one point during debugging I saw that an import in the original test could not be resolved, because no IPackageFragment of that name could be found, because no directory of that name could be found on disk. I don't even think, JLS enforces any directory structure at all, isn't that said to be an implementation detail? I haven't, however, rechecked this right now. Mildly related bugs that were auto-closed time ago: bug 10987, bug 85394