This patch adds a couple new functions to acquire the macro's name, and also expands it, although it doesn't expand the arguments, as seen from the test files.
Details
- Reviewers
george.karpenkov NoQ rnkovacs dkrupp whisperity martong baloghadamsoftware xazax.hun - Commits
- rG7430213d8e11: [analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name and…
rC346095: [analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name and…
rL346095: [analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name and…
Diff Detail
Event Timeline
- Removed the version entry from the plist file,
- Now using TokenConcatenation to print spaces only when needed (this needed for D52988),
- A bit more doc,
- Reorganized ("refactored" would be too strong of a word) getExpandedMacroImpl to make it easier to read.
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp | ||
---|---|---|
730 | Whoa, that's so easy! | |
790–794 | Not sure, random thought: Could this work in fact be done with the static Lexer::getImmediateMacroName() helper? | |
test/Analysis/plist-macros-with-expansion.cpp | ||
31 | Hmm, i think we can use CHECK-NEXT: here, in order to make sure these lines go sequentially. Otherwise this second line may accidentally match someone else's expansion(?). | |
83 | Typo: arguments. |
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp | ||
---|---|---|
790–794 | I need to create a lexer to lex the arguments of function-like macros (which is in part 3), so I can't get away with it I'm afraid :/ |
Please add a test case where a bug path goes through a macro definition and this macro is undefed at the end of the translation unit.
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp | ||
---|---|---|
670 | Maybe it would be worth to move these helpers to a separate file and add some documentation why we actually simulate the preprocessor rather than doing something else. | |
727 | Maybe could directly return ExpansionInfo? | |
737 | I think this local might be redundant. | |
756 | This might not be completely correct. We are using the preprocessor state after processing the whole translation unit rather than the preprocessor state at the expansion location. This might not cause any problems unless there is a collision between macro names and non-macro names. Also, undefs, redefs might cause troubles. | |
799 | Could this assertion fail due to undefs in the code? |
I'll put this patch on hold while I'm investigating the issue @xazax.hun mentioned.
Mind you, again, other patches don't depend strictly on this part, I'll only need to change the for loop. Hopefully. You never know.
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp | ||
---|---|---|
756 | Yup, you're right, I'm afraid :/ I'll investigate whether I can gather the macro definition at the spelling location with Lexer. | |
799 | Yes... yes it could. |
Fixes according to @xazax.hun's remarks. Thanks for catching that, it was a non-trivial cornercase!
- Now I'm acquiring the macro directive history, and choosing the appropriate macro definition in getMacroNameAndInfo
- Rebased to the now commited first part.
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp | ||
---|---|---|
670 | I'm actually a little unsure about that -- I have had similar thought, but the placement here can be justified with a simple "Where else?". But that's a little vague, I'll admit. | |
727 | I renamed the function to be less confusing. Did this address your concern? | |
756 | I'm really-really happy it didn't have to come to that. |
Because i don't know much about macros, i shouldn't be blocking this review on waiting for myself to understand the code :) I guess we'll eventually figure out if something is wrong with it.
One question and one nit otherwise looks good. Feel free to commit once those are resolved without another round of reviews.
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp | ||
---|---|---|
755 | Can't we have troubles with getMacroInfo + undefs here? Wouldn't findDirectiveAtLoc be a safer choice here? | |
833 | I would remove the inline keyword here. I rarely see this in clang codebase. Let's just trust the compiler :) |
- Fixes according to @xazax.hun's observations
Thanks! I'll commit when I have time watch buildbots.
Here's to losing a couple more handfuls of hair, tests break on many platforms, so I reverted it.
Woohoo, it seems to be fine! ^-^
I thought the evaluation order in braced initializer lists are from left to right, but apparently not. Certainly not on windows.
Maybe it would be worth to move these helpers to a separate file and add some documentation why we actually simulate the preprocessor rather than doing something else.