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

Ray Zhang via cfe-dev cfe-dev at lists.llvm.org
Fri Jun 26 23:44:07 PDT 2020

Hi Stephen,

Thank you for the suggestions! And I see the option, I will aim to
contribute it inside of clang-tidy :)

By the way, I have encountered an issue when trying to address the cast
type CastKind::CK_BuiltinFnToFnPtr. According to this demo
<https://godbolt.org/z/aDuLhW>, it is impossible to pass in a builtin
function as a function pointer. In the comments here,
it says "only available from the callee of a call expression". It seems
like I am passing in the function pointer as the callee in my demo, no?


On Sun, Jun 21, 2020 at 4:25 AM Stephen Kelly <steveire at gmail.com> wrote:

> On 20/06/2020 08:21, Ray Zhang via cfe-dev wrote:
> 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.
> Makes sense. You shouldn't be trying to transform instantiations of
> templates. Perhaps issuing a warning as Arthur wrote makes sense though.
> 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++.
> Clang-tidy has plenty of checks which are C++-specific.
> You can make your check c++-specific too:
> bool isLanguageVersionSupported(const LangOptions &LangOpts) const
> override {
>   return LangOpts.CPlusPlus;
> }
> clang-tidy is still an appropriate place for your check.
> Thanks,
> Stephen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200626/1dae6550/attachment.html>

More information about the cfe-dev mailing list