Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] ASTRewrite rewrite



On Thu, Aug 4, 2011 at 4:37 AM, Lukas Felber <lfelber@xxxxxx> wrote:

>
> Please file a bug for the issue with Rename.

Done. https://bugs.eclipse.org/bugs/show_bug.cgi?id=353866

> Please notice that Rename uses somewhat different code that
> CRefactoring2-based refactorings.

I was aware of that. Since rename is the only refactoring which does not
request saving of resources before running, I created the example with
rename.

> Do you have an example of a similar issue for CRefactoring2-based
> refactorings?

Given the reason that all other refactorings than rename (I am on branch
master) request saving before running, I can only give examples by also
disabling this request for saving. This can be achieved by adding
"setSaveRequired(false);" to the constructor of RefactoringActions.

I applied your patch form
https://bugs.eclipse.org/bugs/show_bug.cgi?id=347712 to master for the
following example. Then I added a "setSaveRequired(false);" to
ExtractLocalVariableAction (which extends CRefactoring2) and created a
project containing the following files:

//file A.h
#include "j_def.h"
class A {
 void bar() {
   double i = j;
 }
};

//file j_def.h
int j = 0;

now change "int" int file j_def.h to "double" (do not save). Open file
A.h, select _expression_ "j" and call extract local variable. The
refactoring will work but produce a wrongly typed variable "int j0 =
j;". The type of "j0" should be "double" and not "int". The problem here
again is the indexer is not jet up to date and thus does not jet know
that the type of "j" in j_def.h has changed to "double", meaning that
when determining the type of the _expression_ "j" in A.h it yields "int"
instead of "double".

I can also provide you with malfunctioning examples of
ImplementMethodRefactoring and GenerateGettersAndSettersRefactoring
(which are the only remaining subclasses of CRefactoring2) if you like.

I did no file a bug for the problem described above since the problem is
not yet there (as long as the "setSaveRequired(false);" in the
refactorings' constructors are missing).

This is a very difficult problem to solve in the general case. I propose that we punt on attempts to reflect changes in the unsaved files that only indirectly affect the code being refactored. To illustrate what I mean by "indirectly" lets consider few existing refactorings.

For Extract Local Variable all unsaved changes outside of the file being changed can be ignored. This seems to be a better tradeoff than forcing all files to be saved and waiting for the indexer to reindex them. Automatic refactoring makes sense only when it is faster than making the same change by hand.

For Generate Getters and Setters we can ignore unsaved changes in all files except the one containing the class definition and the one the generated method definitions would be added to.

For Implement Method we can ignore changes in all files except the ones being changed and the ones where the methods being overridden are declared. 

For Rename refactoring we should be able to detect references introduced after the last saving of files, but can ignore other unsaved changes, for example a typedef somewhere, that could potentially add more or eliminate some of the rename candidates.  

Lukas

-sergey 

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top