RefactoringCallbacks and RefactoringTool

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RefactoringCallbacks and RefactoringTool

Roman Popov via cfe-dev
Hello,

how to make RefactoringCallback and RefactoringTool play nicely together? 
Each RefactoringCallback produces its own Replacements, but RefactoringTool wants FrontendActions that populate the Replacements returned by RefactoringTool::getReplacements(). 

I could write an adapter that does this (consume many callbacks, at the end of each translation unit move from replacements and clear the old ones), but that seems pretty inelegant. Do we care about API stability for RefactoringCallback? It might be more elegant to change RefactoringCallback to contain a reference to a map<string, Replacements> and add directly to that. 

Would you be willing to accept a patch that does this? 

Regards,
Julian 

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RefactoringCallbacks and RefactoringTool

Roman Popov via cfe-dev
cc Daniel, who might have more memory of that time :)

On Wed, Feb 1, 2017 at 3:01 AM Julian Bangert via cfe-dev <[hidden email]> wrote:
Hello,

how to make RefactoringCallback and RefactoringTool play nicely together? 
Each RefactoringCallback produces its own Replacements, but RefactoringTool wants FrontendActions that populate the Replacements returned by RefactoringTool::getReplacements(). 

I could write an adapter that does this (consume many callbacks, at the end of each translation unit move from replacements and clear the old ones), but that seems pretty inelegant. Do we care about API stability for RefactoringCallback? It might be more elegant to change RefactoringCallback to contain a reference to a map<string, Replacements> and add directly to that. 

Would you be willing to accept a patch that does this? 

a) we don't care about API stability here - if we find a better way for the API, we go for it
b) I don't think RefactoringCallback is really in use - we built this waaaay back before there was RefactoringTool; are you sure you need it (as opposed to us just deleting it and introducing an abstraction that makes more sense)?
 

Regards,
Julian 
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev