[PATCH] Don't replace macro usage if macro body has NULL
Siraj, Tareq A
tareq.a.siraj at intel.com
Tue Mar 26 13:17:45 PDT 2013
Sorry for the delayed response to this. Playing with your example, I found another bug:
void test_macro_expansion4() {
#define FOO(X) (int*) X ## L
int *p = FOO(0);
// becomes: int *p = nullptr(0);
#undef FOO
}
Not sure if PR15572 will fix this problem entirely but I'll open a bug report for this and revisit this after PR15572 is fixed.
Regarding Start/End location coming from different places, I tried:
void foo2() {
#define FOO(X) X ## ULL
int *p = FOO(N);
#undef FOO
}
And with the http://llvm-reviews.chandlerc.com/D549 patch applied, it seems to be working fine. Thanks.
On 2013-03-21, at 6:13 AM, Manuel Klimek <klimek at google.com<mailto:klimek at google.com>> wrote:
On Wed, Mar 20, 2013 at 5:16 PM, Tareq A. Siraj <tareq.a.siraj at intel.com<mailto:tareq.a.siraj at intel.com>> wrote:
================
Comment at: cpp11-migrate/UseNullptr/NullptrActions.cpp:125
@@ +124,3 @@
+ // coming from a macro called NULL.
+ if (SM.isMacroArgExpansion(StartLoc) && SM.isMacroArgExpansion(EndLoc)) {
+ StartLoc = SM.getFileLoc(StartLoc);
----------------
Manuel Klimek wrote:
> I assume we don't care that those can both be true, but start and end can still be produced from different macro expansions? Or do we check that somewhere else?
Can you provide an example for start/end coming from different macro expansions in case of ImplicitCastNodes? I don't think we do this check but is it really necessary for ImplicitCastNodes? Thanks.
Well, I'm not sure. What about:
#define B(X) X ## .742
void f(int i) {
f(B(3));
}
--
Tareq A. Siraj
Software Developer
SSG/DPD/ECDL/DMP
Phone: +1 519 772 2577
More information about the cfe-commits
mailing list