> On Sep 10, 2015, at 12:22 PM, Angel Garcia via cfe-commits
> wrote:
>
> Hi Argyrios,
>
> Thank you for your answer. I think that it is pretty clear that we don't
> really want to allow changes like the one in your example. But my problem is
> almost the opposite. I have something like this
Hi Argyrios,
Thank you for your answer. I think that it is pretty clear that we don't
really want to allow changes like the one in your example. But my problem
is almost the opposite. I have something like this:
#define MY_MAC(x,y) doSomething(x, y);
which is used in this way:
MY_MAC(var1, var1
Hi Angel,
This part of the code is conservative because it is not clear if accepting the
change in all the different places where the macro argument is expanded is
acceptable or not.
For a contrived example, let’s say you have this macro definition:
#define MY_MAC(x) foo(x) + bar(x)
an
+ Argyrios
Hi Angel,
I believe Argyrios is the original author of the code in question, as this
looks related to the Objective-C “modernizer” migrator he wrote a while back.
This code started life on our internal development branch at Apple related to
an Xcode feature we were doing, and I did
+cfe-commits
On Tue, Sep 8, 2015 at 6:56 PM, Angel Garcia wrote:
> Hi Ted,
>
> I was working on a clang-tidy check, and today I discovered that it was
> unable to do several replacements in different arguments of the same macro
> call. At first, I thought it was a bug, and trying to figure out w
