From what I can see, this should be the last patch needed to replicate macro argument expansions.
Thanks again to @donat.nagy for spotting this!
Details
Details
Diff Detail
Diff Detail
Event Timeline
Comment Actions
This patch didn't really work, sometimes it printed extra spaces, sometimes printed the hash tokens, and so on, so I refactored the whole project to deal with this issue almost out of the box.
Comment Actions
Looks good.
What happens if the macro is to stringify a partially string argument?
#define BOOYAH(x) #x ";
...
std::string foo = BOOYAH(blabla)
std::string foo2 = BOOYAH("blabla)
int x = 2;Not sure if these cases are even valid C(XX), but if they are, we should test.
An idea for a follow-up patch if it's not that hard work: you mentioned your original approach with that madness in the HTML printer. Perhaps it could be refactored to use this implementation too and thus we'll only have 9 places where macro expansion logic is to be maintained, not 10. 😈
Comment Actions
I verified this project on tmux, which uses the preprocessor very heavily. It works perfectly, and doesn't crash anywhere despite the very liberal use of asserts.
Lucky, this spawn of a nightmare doesn't compile.
An idea for a follow-up patch if it's not that hard work: you mentioned your original approach with that madness in the HTML printer. Perhaps it could be refactored to use this implementation too and thus we'll only have 9 places where macro expansion logic is to be maintained, not 10. 😈
The HTML output contains the macro expansions for all macros in the file, so it's justifiable that entire file is lexed and preprocessed. Granted, using const_cast and the like (there are some next level hacks in that implementation) is risky, but as long as it doesn't break, it does it's job better then this solution would.
As long as it doesn't break. If you generate a HTML output, the report generation speed may not be the greatest concern, so I'll definitely think about this a little bit.