This patch moves the logic around slightly to handle macros better; instead of relying on the PP Lexer, we track the information in the PP itself so that is is always available. I've expanded the test cases to cover macros more fully.
Thanks! ~Aaron On Tue, Jan 15, 2013 at 7:52 PM, Aaron Ballman <[email protected]> wrote: > As far as I can tell, the only way to handle that case would be to > track whether we're in a preprocessor directive as part of > Preprocessor's state instead of just PreprocessorLexer. Unless > someone sees another way that I'm not familiar with? > > ~Aaron > > On Tue, Jan 15, 2013 at 7:13 PM, Aaron Ballman <[email protected]> wrote: >> Unfortunately, we can't. Consider: >> >> #define MACRO1 __has_include(<stdint.h>) >> >> #if !MACRO1 >> #error "__has_include with macro failed (1)." >> #endif >> >> However, my patch doesn't address the usage of macros. I'll explore a >> bit to see if there's something more I can do in that case. >> >> ~Aaron >> >> On Tue, Jan 15, 2013 at 6:58 PM, Dmitri Gribenko <[email protected]> wrote: >>> On Wed, Jan 16, 2013 at 1:49 AM, Aaron Ballman <[email protected]> >>> wrote: >>>> 3 -- if there's not a current lexer, we have no way to know we're >>>> currently in a preprocessor directive (that I'm aware of). >>> >>> Is there a case where we use this mode to parse a pp directive? Can >>> we always emit an error in this case? >>> >>> Dmitri >>> >>> -- >>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if >>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <[email protected]>*/
pr14837.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
