[cfe-dev] (no subject)

Steven Lu via cfe-dev cfe-dev at lists.llvm.org
Tue Nov 15 18:53:13 PST 2016


Thanks!

Now that I can see the errors, they say that my replacements conflict with
each other.

It seems to me that if I make multiple replacements placed at the same
location, which all replace zero characters, this shouldn't be treated as a
conflict. This is in fact what I am seeing. Could you comment on that?

Am I to understand that the replacement subsystem is in a state of flux at
the moment?

Thanks a lot!
Steven

On Tue, Nov 15, 2016 at 2:06 PM, Eric Liu <ioeric at google.com> wrote:

> You can use "llvm::toString(std::move(Err))" to convert the returned
> error to string.
>
> Thanks for pointing this out :) I'll mention this in the doc.
>
> On Tue, Nov 15, 2016 at 7:40 PM Steven Lu <stevenlu443 at gmail.com> wrote:
>
>> I do have one more question.
>>
>> The return value of add() is an llvm::Error.
>>
>> I'm now finally able to compile the code, but I'm having a ton of trouble
>> figuring out how to print such an error to a string stream of any kind.
>> Google is no help here.
>>
>> Thanks!
>>
>> On Mon, Nov 14, 2016 at 4:06 PM, Steven Lu <stevenlu443 at gmail.com> wrote:
>>
>> Hi Eric,
>>
>> Thanks for clarifying. The only confusion I have is that previously the
>> API was easier to use. Now I have to call Replacement.getFilePath() and
>> explicitly index the filename map. It feels almost like maybe instead of
>> getReplacements() returning a std::map maybe this could be (yet another)
>> class so we can continue to have this straightforward interface.
>>
>> It also prompts me to wonder what other use cases that this change helps
>> with.
>>
>> As for doc I'm sure that just adding a note of what you said (use
>> Replacement.getFilePath() to index to the map) would have been enough to
>> get me there. I hadn't realized that Replacement could fetch the file path.
>>
>> Thanks
>>
>> On Mon, Nov 14, 2016 at 6:30 AM, Eric Liu <ioeric at google.com> wrote:
>>
>> A common way is to use the file path in a replacement, i.e.
>> `Replaces[R.getFilePath()].add(R)`. Note that
>> clang::tooling::Replacements
>> <https://github.com/llvm-mirror/clang/blob/master/include/clang/Tooling/Core/Replacement.h#L146>
>> is now implemented as a class instead of a std::set.
>>
>> In general, `formatAndApplyAllReplacements` is a function you would use
>> to apply changes while format changed code *after* you've got all
>> replacements. A sample usage can be found in clang-move
>> <https://github.com/llvm-mirror/clang-tools-extra/blob/master/clang-move/tool/ClangMoveMain.cpp#L137>.
>> And I think the interface's comment does explain its purpose. Which
>> specific part did you find confusing? I'm happy to improve the doc :)
>>
>> - Eric
>> On Mon, Nov 14, 2016 at 12:04 PM Manuel Klimek <klimek at google.com> wrote:
>>
>> +eric
>>
>>
>> On Sat, Nov 12, 2016 at 10:45 AM Steven Lu via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>> I've updated clang from revision 254425 to 286122, and RefactoringTool::
>> getReplacements() now produces a map of files to replacements.
>>
>> My original code implements a MatchFinder::MatchCallback which takes a
>> pointer to the return value of RefactoringTool::getReplacements() and
>> simply inserts Replacements, now it is not clear how I am to perform the
>> insertion, I cannot tell now if there is some canonical way to determine
>> the filename string to save a particular Replacement under.
>>
>> I have also found the function formatAndApplyAllReplacements which I'm
>> having trouble finding doc/instructions for and seems to be a highest-level
>> function that I should use, but it doesnt seem to help address this
>> problem.
>>
>> I wonder if someone could do a quick rundown of how to use the interface
>> in a proper way.
>>
>> Thanks
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161115/f49c990b/attachment.html>


More information about the cfe-dev mailing list