On Wed, Jul 20, 2011 at 6:14 AM, Tomasz Wesołowski
<kosashi@xxxxxxxxx> wrote:
Hello,
Recent development of Codan (and Refactoring) more and more often uses ASTRewrite, and - logically - more and more reveals problems with it. Currently known issues mentioned here and there on Bugzilla include:
- rewriting from scratch a whole Editor section from the first change to the last, even when everything inside is unchanged
I'm planning to work on that, but any help will be appreciated. See the cdt-dev thread entitled ASTRewrite question.
- unwinding macros
This is related to excessive rewrite. On top of that we need protection against modifying code produced by macro expansion.
- eating comments
Partially related to excessive rewrite. Generate getters and setters refactoring doesn't eat comments, so it's possible to do even now.
- generating wrong formatting
Rewritten code has to be reformatted, but in order to do that we need to fix excessive rewriting first.
- requiring the file to be saved (unlike JDT, where you can do quick fixes and refactoring directly on a dirty working copy, without forcing save)
- lack of reasonable ability to get file locations of newly created AST nodes (they are needed to create neat linked editor sections for user input after refactoring)
I don't understand the part in paretheses.
- other strange magic (bug 321071 for instance)
ChangeGenerator is buggy and unnecessarily complex because of excessive rewrite that happens earlier.
There's been some significant progress on patching the most dramatic issues (see for example bug 296192 and especially its subtasks), but there are still a lot of open issues (like the first bullet point of my list), rooting in some design decisions between ASTRewrite.
--
I'm considering whether it is feasible to actually rewrite this module on different assumptions (work on a working copy, don't concatenate all singular changes to one big mega-change as it's done now, try to keep the result as close to original as possible). Let me stress that ASTWriter (the part responsible for generating new code fragments) works cool and the "only" thing I'm referring to right now is how the code changes are incorporated later on. Still not a small task, but might be worth a shot... And probably a big step towards JDT's quality in terms of editor experience.
All refactorings except Rename are unusable at this point. The problems you outlined have to be solved to claim that CDT supports refactorings beyond simple rename.
What do you think?
Best regards,
Tomasz Wesołowski
-sergey
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
