[cfe-dev] Questions/discussions about cast types in clang

[Ray Zhang via cfe-dev]

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 <typename T> void foo() { int* ptr; (T*) ptr; }

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.

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: 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.

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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200620/ce3df1b1/attachment.html>