Questions/discussions about cast types in clang

Clang Frontend
1

Hi all,

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:

  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:

template void foo() { int* ptr; (T*) ptr; }

If we call foo, it can be a const_cast, but if we call foo, 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.

  1. (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: https://godbolt.org/z/rp8DDt. The first statement is not a cast, but rather a CompoundLiteralExpr(InitListExpr(…)), and should not be treated as a cast. Here is the corresponding GCC document: https://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html about union casts. If CastKind::CK_ToUnion is ever encountered in my program, I will leave the C-style cast as is.

  2. (Question) In general, should this tool for C++ also support OpenCL and Objective C++? Technically, const/static/reinterpret_casts exist in those languages (see https://godbolt.org/z/DEz8Rs 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: https://clang.llvm.org/extra/clang-tidy/#id2. In the main driver I will explicitly check whether the program is in C++.

I’d appreciate any questions/concerns, or oversight on my part on the 3 issues above. Thanks!

Best,
Ray Zhang