Community
Participate
Working Groups
Build 20031023 With JDT Core source project, select type org.eclipse.jdt.internal.compiler.ast.AstNode and rename it into: ASTNode Refactoring will notice there is a DOM type with the same name; but when proceeding it will fail to update properly DOM code which was referring to AstNode and ASTNode (old references to AstNode should have been converted to org.eclipse.jdt.internal.compiler.ast.ASTNode to avoid confusion).
Rename type is fully search engine based. So if we miss some references then they are not present in the search result or they are reported as inexact matches. We ignore inexact matches since we can't be sure that we are doing the right thing. Philippe, do you remember which CU didn't get updated.
Sources living in package org.eclipse.jdt.core.dom which were referring to AstNode through an import (and also to the homonym ASTNode which lives in the same package). I suspect the check for conflicts did not notice there was another sibling type within the same package, and thus did not need any import. An example is org.eclipse.jdt.core.dom.AstConverter, which is correctly found as a reference to type AstNode.
The rename refactoring issues a warning that 3 compilation units reference a different type ASTNode. This is a clear indication that the refactoring will not produce a correct result. Doing the right thing in this case is to convert all unqualified references to AstNode to fully qualified references to AstNode to make sure they don't conflict with each other. But this requires a rewrite of rename, since the current rename isn't AST based (it is based on position reported from the search engine). Problematic is that we only issue a warning here. It should be an error.
Upgraded the warning to an error. Updating the references to fully qualified references has to wait until we recode the refactoring to be AST based. Doing so will allow to remove the issued warnings/errors.
Sounds fair for now
*** This bug has been marked as a duplicate of 33222 ***
