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

[Ray Zhang via cfe-dev]

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,
<https://github.com/llvm/llvm-project/blob/77d76b71d7df39b573dfa1e391096a040e9b7bd3/clang/include/clang/AST/OperationKinds.def#L339>
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?

Best,
Ray

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>