<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. 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><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">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">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><br></div><div>3. (Question) In general, should this tool for C++ also support OpenCL and Objective C++? Technically, const/static/reinterpret_casts exist in those languages (see <a href="https://godbolt.org/z/DEz8Rs">https://godbolt.org/z/DEz8Rs</a> for example). In my opinion, I think the casting tool should strictly adhere to C++ as the language of support and nothing more for the first iteration because different coding standards may be held for different languages(and I only have ample experience with C++). As a result, I propose that the first iteration of the casting tool be placed outside of clang-tidy as clang-tidy also supports Objective C (but not OpenCL), as seen here: <a href="https://clang.llvm.org/extra/clang-tidy/#id2">https://clang.llvm.org/extra/clang-tidy/#id2</a>. In the main driver I will explicitly check whether the program is in C++.</div><div><br></div><div>I'd appreciate any questions/concerns, or oversight on my part on the 3 issues above. Thanks!</div><div><br></div><div>Best,</div><div>Ray Zhang</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>