Typz added a comment.
Indeed, I saw the emails, but I didn't have time to check or investigate the
issues.
As for E, this is more tricky than this. At the moment, the code does not look
at what is in the first "branch" of the ternary operator : it does not care if
this is a nested ternary operator as well... (which would probably add *many*
more cases to handle). So, at the moment,
return temp[0] > temp[1] ? temp[0] > temp[2] ? 0 : 2
: temp[1] > temp[2] ? 1
: 2;
is equivalent to:
return temp[0] > temp[1] ? myFieldWithVeryLongName
: temp[1] > temp[2] ? 1
: 2;
which looks fine....
At some point, once I had a working change I tried to improve it so that the
decision would not be "hardcoded" but penalty-based, but I did not succeed in
this.
In this specific case, once option may be to introduce a special case for
"balanced ternary operator", e.g. at least in the most simple case (e.g. a ? b
? c : d : e ? f : g), though there may be a more generalized form... Not sure
exactly how easy/complicated it would be, though...
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D50078/new/
https://reviews.llvm.org/D50078
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
