Skip to content

Conversation

@MitchBriles
Copy link
Contributor

Fixes #169197. This also seems to improve diagnostics in some cases. Let me know if this is not the expected behavior.

Note: I am new to this part of the project. I would appreciate any feedback/nits.

cc: @Sirraide, @Fznamznon

@Sirraide
Copy link
Member

I’m not entirely sure that issue is even an issue (see the comment I left there)

Comment on lines +4250 to +4255
if (const ConditionalOperator *Cond = dyn_cast<ConditionalOperator>(E)) {
if (FieldDecl *FD = Cond->getTrueExpr()->getSourceBitField())
return FD;
if (FieldDecl *FD = Cond->getFalseExpr()->getSourceBitField())
return FD;
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this mean the order of the second and third operands would matter? Also, it looks like it would make cond?bit-field:non-bit-field promote and check for narrowing conversions based off of the width of the bit-field. Therefore promotion could change the value if the non-bit-field had a value not representable in int but representable in unsigned, and narrowing could happen in contexts where narrowing conversions are disabled.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if the operands differ in that way, it's handled in Sema::CXXCheckConditionalOperands. If folks can agree on the expected behavior, I'll make sure my patch is correct before marking it as ready.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Conditional operators that result in bit-fields do not correctly preserve the width

3 participants