fix #13954: Unnamed bit fields are removed. #7611
Conversation
ludviggunne
force-pushed
the
13954
branch
8 times, most recently
from
263ea07 to
3f9f968
Compare
ludviggunne
force-pushed
the
13954
branch
2 times, most recently
from
5859d52 to
491e305
Compare
|
what does the test-my-pr.py say? are there diffs..? |
I've only run it with e2764f0 so far, so I should probably run it again. There are some diffs, most of them seem to be eliminated false positive similar to #13653 & #13850. |
| tok->deleteNext(4 + tokDistance(tok, typeTok) - 1); | ||
| goback = true; | ||
| const std::size_t id = anonymousBitfieldCounter++; | ||
| const std::string name = "anonymous@" + std::to_string(id); |
There was a problem hiding this comment.
I can accept that we use @ here. but the unfortunate side is that we also use @ in debug output to show varid.
But I think we developers can adapt.
There was a problem hiding this comment.
I figured a colon might be confusing since we're dealing with bitfields. Is there some other character that doesn't appear in other contexts?
| testBitfields("unsigned int a : 16;\n" | ||
| "unsigned int : 0;\n" | ||
| "unsigned int b : 16;\n", | ||
| 8); |
There was a problem hiding this comment.
These test cases looks unfortunate to me. It's platform dependent what the sizeof is for this struct isn't it?
Does the standard say what happens when a bitfield has size 0?
There was a problem hiding this comment.
Yep, from cppreference:
The special unnamed bit-field of size zero can be forced to break up padding. It specifies that the next bit-field begins at the beginning of its allocation unit
But yes, the size can vary since the size of int can vary.
There was a problem hiding this comment.
i.e. I would assume there are compilers that will determine that the size is 4 bytes here.
There was a problem hiding this comment.
Iv'e added code to force using unix 64 platform in the tests.
No description provided.