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