courbet added a comment. Thanks for the details, this explains the motivation well. I think the key point is the combination of:
> It turns out doing anything useful with a bitfield will eventually result in > an integral promotion, which mandates that the type must be 'int' if it fits > conv.prom/5: <https://eel.is/c++draft/conv.prom#5> > >> A prvalue for an integral bit-field ([class.bit]) can be converted to a >> prvalue of type **int if int can represent all the values of the >> bit-field**; otherwise, it can be converted to unsigned int if unsigned int >> can represent all the values of the bit-field. If the bit-field is larger >> yet, no integral promotion applies to it. If the bit-field has an enumerated >> type, it is treated as any other value of that type for promotion purposes. and > shift expression is the only one whose return type depends only on the > //left// operand So adding that as a comment above `ShiftingWidenedBitfieldValue` would help. Maybe also add a note in the comment that we are not interested in whether the shift itself might overflow. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D114105/new/ https://reviews.llvm.org/D114105 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
