[PATCH] D27054: Introducing clang::tooling::EditList for refactoring tools.
Eric Liu via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Nov 30 06:01:34 PST 2016
ioeric added inline comments.
================
Comment at: include/clang/Tooling/Refactoring/EditList.h:41
+ /// \brief Creates an edit list for a key position.
+ EditList(const SourceManager &SM, SourceLocation KeyPosition);
+
----------------
ioeric wrote:
> klimek wrote:
> > ioeric wrote:
> > > djasper wrote:
> > > > I wonder whether we should always use a SourceLocation as key or whether we want to leave this up to the users. E.g. we could make this take a string parameter and provide a
> > > >
> > > > string getKeyForLocation(const SourceManager &SM, SourceLocation KeyPosition);
> > > I think the key idea of EditList is that it groups a set of edits around a key position. For refactoring, using position as key makes sense to me (since all edits will be around some position), and I couldn't think of other things that are good to be a key here.
> > An idea would be an edit that just inserts multiple headers, but does not directly touch a source location (thus, we might want to key things off of files?).
> We could make the key position the start of the file in this case. But looks like a customize-able key could potentially enable more opportunities, I'll go with Daniel's suggestion. Thanks!
So I tried the `getKeyForLocation` way, but we still need `FilePath` in the constructor to fully initialize an EditList.
I think it might be better if we keep the current constructor (since this will be the most-commonly used one IMO) and adds another constructor that takes `FilePath` and `Key`.
https://reviews.llvm.org/D27054
More information about the cfe-commits
mailing list