<div dir="ltr"><div dir="ltr"><div dir="ltr">On Sat, Jun 20, 2020 at 3:31 PM Ray Zhang via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>I'm currently implementing a clang tool to replace C style casts to C++ style casts, i.e. const/static/reinterpret_casts. I'm almost done, but I've ran into a collection of issues/questions that I'd like to raise here to make sure it's not a misunderstanding on my part. My solutions are included in each bullet point:</div><div><br></div><div>1. (Question) For dependent types, it is unknown whether static_cast or reinterpret_cast is appropriate for the situation, so I would like to leave that as a C-style cast in the refactor tool. Example below:</div><div><br></div><div><span style="color:rgb(28,30,33);font-family:monospace;font-size:15px;white-space:pre-wrap;background-color:rgb(253,245,212)">template <typename T>
void foo() {
    int* ptr;
    (T*) ptr;
}
</span><br></div><div>If we call foo<int>, it can be a const_cast, but if we call foo<double>, it has to be a reinterpret_cast.</div></div></blockquote><div><br></div><div>It could even involve both a const_cast and a static_cast; or it could be unrepresentable as a non-C-style cast (e.g. a cast to a private base).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> In a situation where the user is writing library code, it won't only be relevant to the current translation unit but also for future purposes. Therefore, I propose that we leave dependent type c-style casts as they are.</div></div></blockquote><div><br></div><div>Sounds reasonable. Although, it would be nice to flag such casts for human inspection somehow; see my very informal proposal <a href="https://quuxplusone.github.io/blog/2020/01/22/expression-list-in-functional-cast/#it-would-be-useful-for-clang-or">here</a> for example.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>2. (Issue/bug) In OperationKinds.def, there is an enum detailing casting to union types. This doesn't work in clang(nor GCC). Here's a compiler explorer MVCE: <a href="https://godbolt.org/z/rp8DDt" target="_blank">https://godbolt.org/z/rp8DDt</a>. The first statement is <i>not a cast</i>, but rather a CompoundLiteralExpr(InitListExpr(...)), and should not be treated as a cast. Here is the corresponding GCC document: <a href="https://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html" target="_blank">https://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html</a> about union casts. If CastKind::CK_ToUnion is ever encountered in my program, I will leave the C-style cast as is.</div></div></blockquote><div><br></div><div>It works in GCC trunk for me... but only in C++20 mode.</div><div><a href="https://godbolt.org/z/Qjpxga">https://godbolt.org/z/Qjpxga</a><br></div><div>I suspect that your analysis is still correct: this feature is documented, but does not work, in GCC pre-C++20, and then in C++20 the changes around parens-initialization of aggregates broke it in such a way that now it <i>appears </i>to work but nobody should trust it to <i>actually </i>work. It might be nice to submit a patch ripping this broken stuff out of Clang and/or out of GCC.</div><div><br></div><div>my $.02,</div><div>–Arthur</div></div></div></div>