<div dir="ltr"><div>Hi Stephen,</div><div><br></div><div>Thank you for the suggestions! And I see the option, I will aim to contribute it inside of clang-tidy :) <br></div><div><br></div><div>By the way, I have encountered an issue when trying to address the cast type CastKind::CK_BuiltinFnToFnPtr. According to this <a href="https://godbolt.org/z/aDuLhW">demo</a>, it is impossible to pass in a builtin function as a function pointer. In the comments <a href="https://github.com/llvm/llvm-project/blob/77d76b71d7df39b573dfa1e391096a040e9b7bd3/clang/include/clang/AST/OperationKinds.def#L339">here,</a> 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?</div><div><br></div><div>Best,</div><div>Ray<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 21, 2020 at 4:25 AM Stephen Kelly <<a href="mailto:steveire@gmail.com">steveire@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <p><br>
    </p>
    <div>On 20/06/2020 08:21, Ray Zhang via
      cfe-dev wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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>
    </blockquote>
    <p><br>
    </p>
    <p>Makes sense. You shouldn't be trying to transform instantiations
      of templates. Perhaps issuing a warning as Arthur wrote makes
      sense though.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite">
      <div dir="ltr">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" target="_blank">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" target="_blank">https://clang.llvm.org/extra/clang-tidy/#id2</a>.
        In the main driver I will explicitly check whether the program
        is in C++.</div>
    </blockquote>
    <p><br>
    </p>
    <p>Clang-tidy has plenty of checks which are C++-specific.</p>
    <p>You can make your check c++-specific too:</p>
    <p><br>
      bool isLanguageVersionSupported(const LangOptions &LangOpts)
      const override {<br>
        return LangOpts.CPlusPlus;<br>
      }<br>
    </p>
    <p>clang-tidy is still an appropriate place for your check.</p>
    <p>Thanks,</p>
    <p>Stephen.<br>
    </p>
    <p><br>
    </p>
  </div>

</blockquote></div>