mjacobse wrote:
Yeah that makes sense to me. So I reverted this attempt of just checking if we
are in some kind of ListInit, it does not work.
It looks like expressions like `double{f}` turn into a `CXXFunctionalCastExpr`
just like `double(f)`, with the only difference that for `double{f}` the
`CXXFunctionalCastExpr` gets an additional direct child `InitListExpr` with one
initializer. So the implicit conversion analysis does skip over
`CXXFunctionalCastExpr` as an explicit cast, but not over the `InitListExpr`,
causing the warning. But it seems like at least for this purpose,
`InitListExpr` basically belongs to the explicit cast still, so I added some
code to skip it too in this case. And this seems to work as intended.
The implementation is not the prettiest though and it seems to rely heavily on
this implicit assumption that `InitListExpr` as a direct child of
`CXXFunctionalCastExpr` means that we have this special case of
list-initialization. I'd be very happy about suggestions for how to improve
this.
I also applied the test deduplication that you suggested and added some tests
for classic function-style casts and the initialization examples that showed
that the previous fix was broken. I can add further suggested tests involving
classes and templates later if the new fix turns out to be the right idea.
I also introduced an alias for `long double` in the tests to write
`LongDouble{f}` instead of `(long double){f}`. The latter did not do what I
expected, instead it results in a C99 compound-literal construction (which does
trigger `-Wc99-extensions`). These actually produce the `-Wdouble-promotion`
warning too while they probably shouldn't, but I suppose that's something for a
different issue.
https://github.com/llvm/llvm-project/pull/159992
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
