[LLVMbugs] [Bug 9799] New: MacroExpands callback invoked when the macro should not be expanded

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=9799

           Summary: MacroExpands callback invoked when the macro should
                    not be expanded
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ori at avtalion.name
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6506)
 --> (http://llvm.org/bugs/attachment.cgi?id=6506)
Move the callback invocation after the validity checks

The MacroExpands is invoked when macro FOO(a) is defined, and token FOO is
encountered.

Since FOO isn't a function-like token (that is followed by a parentheses), no
expansion should occur.

I don't think the task of checking this should be left to the callback
receiver.

The macro expansion code (Lex/PPMacroExpansion.cpp,
Preprocessor::HandleMacroExpandedIdentifier) seems to immediately invoke the
callback, before performing any of the checks that might result in the macro
not being expanded.

The actual callback should be delayed as late as possible.

Reading the code, I can see several more situations where the callback should
not be invoked:
* A function-like macro not having the exact number of arguments.
* A macro being a builtin like __LINE__ (Not sure about that. Might be useful)

The attached patch moves the callback invocation to be after the validity
checks. If it is decided that builtin macros are worthy of a callback, the line
can be copied inside the "if (MI->isBuiltinMacro())" condition.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.