On the newly included test case the previous behavior was
Line 53: note: Assuming 'i' is equal to nested_null_split
which is meh.
I tried to make this piece of logic slightly more correct, but it's most likely still completely incorrect.
Differential D59121
[analyzer] Fix macro names in diagnostics within bigger macros. NoQ on Mar 7 2019, 5:33 PM. Authored by
Details
On the newly included test case the previous behavior was Line 53: note: Assuming 'i' is equal to nested_null_split which is meh. I tried to make this piece of logic slightly more correct, but it's most likely still completely incorrect.
Diff Detail Event TimelineComment Actions Uhh, it's such a chore to work on these things -- You can really feel that the preprocessor must've been the first thing implemented in clang. Unfortunately, you really have to counterweight it's shortcomings with excessive amount of comments. I can see an infinite loop and a lot of string comparisons, but someone without having this particular test case as a context, it's very hard to follow what's happening. Could you please add some code examples in the comments too?
Comment Actions An elegant solution for a more civilized age. Unfortunately, doesn't preserve the UINT32_MAX macro in the newly added test - i'll try a bit harder to preserve it. Relies on D59977 to work. Comment Actions I think the right thing to do here is "look at the immediate macro; while it expands exactly to our original expression, look at what it is an expansion of; write down the last macro we've reached". My code now gives up whenever we stop expanding to the original expression, but it should write down the highest macro it has reached instead. Comment Actions On second thought, dunno. In the scan-build macro preview it wouldn't show you UINT32_MAX anyway. Maybe let's keep this behavior. Cleaned up the patch a little bit. Comment Actions Somehow on the Assuming ... pieces we write out the macro name, and my little code did that too. We could obtain the value but I think your first intention is the correct behaviour. Why are you not using my working example? Comment Actions Mmm, that *is* an Assuming... piece, i.e., this is the same code, just the structure of macros is more complicated than usual. Comment Actions You told me we would like to see a value when we hover over a name, which is cool. If I think about C and they do not C# over the complicated macros, I would like to C names of macros. It is up to you, but your first intention working with my code very well. Comment Actions Also, this is kinda weird. According to my logic, we should have written Assuming 'i' is equal to 4294967295 because that's what the user will see in the macro popup. However, that's incorrect for the same reason: i is an int, while 4294967295 doesn't fit into an int, so they can never be equal. Writing Assuming 'i' is equal to UINT32_MAX is incorrect for the same reason, and the current message is the only one that's technically the truth. Writing what exactly we're assuming is, in my opinion, more important than repeating what's literally written in the code. Added a FIXME test to document this problem. |
ParentName?