Community
Participate
Working Groups
I200410260800, same in 3.0.0. Maybe connected to bug 77273. - new workspace, autobuild on, new project "J" with p/C.java: package p; class C { } class CC extends C { void method() { } } - copy C.java, paste it again, resolve name conflict with new name "D" => autobuild incrementally compiles D.java => Problems View: "The type CC is already defined" in D.java, *no line* - clean the project => autobuild does full build => Problems View: "The type CC is already defined" in D.java, *line 5* (range: CC) Expected: same range in both cases
In the full build case, the compiler creates the error on the type declaration of the duplicate type, since it has all the types in source form. In the incremental case, the builder detects the error when the classfile collides with an existing class file from another source file. We do not know nor have access to the parsed structure. Not sure we'll change this. Philippe?
Can we blame both source files each time ?
Markus: do you care which range you get? No line vs. line 5...
As a user, I would prefer the exact range. As a refactoring implementor, I don't care, since I'm not affected. It's just not nice to see the marker jumping. Maybe Martin has an opinion here, since we could offer a QuickFix for this problem. However, I don't think that it could be more than a "Rename in file".
The name range would of course be nice for quick fix. But there's currently no fix implementented for this problem
Philippe: I've looked around in the JavaModel but I cannot find the source position of a type's name. Is it possible to retrieve just the position of the name, not the entire type declaration?
IMember has a query ISourceRange getNameRange(). This is inherited by IType.
thanks Markus. We now highlight the type name in both cases.
The type is highlighted, but there is no line in the first case. Is this expected?
Verified in 200412142000
Sorry, this does not seem to be fixed properly in I20041221-0800. When I repeat the steps from comment 0 with all editors closed, the Problems View still doesn't show a line number, and doubleclicking the error selects the first character in D.java. The behaviour is different when C.java is opened in the java editor before the steps are executed: The Problems View still doesn't show a line number, but the error range is "CC" in D.java (correct range). When the copy is called "CopyOfC", the Problems View still doesn't show a line number, and the error range is "cl" in "class CC extends CopyOfC" in CopyOfC.java (incorrect range).
So is the line number of the type name available from IType? I don't see it. Unlikely we can do more than we have.
I don't think that the IType knows about line numbers. I think we can live without a line number here, if that resolution (building a Document and asking it) is too expensive. However, I mainly reopened the bug because of the incorrect range problems when the editor is not open or when the copy is called "CopyOfC".
Jerome, can you please have a look at this one. Follow the steps in comment 11. Can the Java Model not answer the source range of a type if an editor is not open?
AbtractImageBuilder#acceptResult(...) was using IJavaProject#findType(...) for a secondary type. This doesn't work if the editor containing the secondary type is closed. Changed AbtractImageBuilder#acceptResult(...) to first find the main type, then construct the secondary type from this main type. Added regression test IncrementalTests#testAddDuplicateSecondaryType()
Verified in I20050214-0927
