Fix PR1820, an incredibly subtle macro expansion bug that Neil discovered.

Neil, please review this fix.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@44285 91177308-0d34-0410-b5e6-96231b3b80d8

2 files changed, 16 insertions, 0 deletions

diff --git a/Lex/Preprocessor.cpp b/Lex/Preprocessor.cpp
index 0970590afe..a685b0b27b 100644
--- a/Lex/Preprocessor.cpp
+++ b/Lex/Preprocessor.cpp
@@ -941,6 +941,16 @@ MacroArgs *Preprocessor::ReadFunctionLikeMacroArgs(Token &MacroName,
         // If this is a comment token in the argument list and we're just in
         // -C mode (not -CC mode), discard the comment.
         continue;
+      } else if (Tok.is(tok::identifier)) {
+        // Reading macro arguments can cause macros that we are currently
+        // expanding from to be popped off the expansion stack.  Doing so causes
+        // them to be reenabled for expansion.  Here we record whether any
+        // identifiers we lex as macro arguments correspond to disabled macros.
+        // If so, we mark the token as noexpand.  This is a subtle aspect of 
+        // C99 6.10.3.4p2.
+        if (MacroInfo *MI = getMacroInfo(Tok.getIdentifierInfo()))
+          if (!MI->isEnabled())
+            Tok.setFlag(Token::DisableExpand);
       }
   
       ArgTokens.push_back(Tok);
diff --git a/test/Preprocessor/macro_disable4.c b/test/Preprocessor/macro_disable4.c
new file mode 100644
index 0000000000..4858813a0e
--- /dev/null
+++ b/test/Preprocessor/macro_disable4.c
@@ -0,0 +1,6 @@
+// RUN: clang -P -E %s | grep 'int f(void)'
+// PR1820
+
+#define f(x) h(x
+#define h(x) x(void) 
+extern int f(f));