<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Kirill,</p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 25.08.2018 um 12:25 schrieb Kirill
Bobyrev:<br>
</div>
<blockquote type="cite"
cite="mid:FA1AEB65-3048-419E-A1FB-9F422938A5A3@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Hi Jonas,
<div class=""><br class="">
</div>
<div class="">I believe that your use-case is slightly different
from what Clang-Refactor tries (or, to be honest, is supposed to
try) to support. Basically, Clang-Refactor should be able to
process refactoring queries from the user coming from the
editor, command line or any other way.</div>
</blockquote>
I thought this could be done from clang-tidy as well. E.g. making
all locals const workflow:<br>
<br>
1. Do the analysis and find all possible const variables<br>
2. Isolate their declaration (unfolding the decl stmts) (just call
the refactor framework maybe with the DeclStmt as argument)<br>
3. Change Qualifier -> adding const (another call to the
refactoring framework)<br>
<br>
Clang-tidy would then just manage the actual workhorses beeing
analysis facilities (the const-thing lives in clang-tidy repo at the
moment) and the high level refactorings.<br>
<br>
I guess it would be an issue to have these steps separated, because
the source-to-source transformation probably requires a rebuild of
the AST to reliably do the next refactoring etc.<br>
<br>
And an editor integration automatically benefits from the
refactorings clang-tidy can do. But here 'clangd' is probably the
key.<br>
<blockquote type="cite"
cite="mid:FA1AEB65-3048-419E-A1FB-9F422938A5A3@gmail.com">
<div class="">From my perspective, your use-case perfectly fits
into the scope of Clang-Tidy: what you propose seems more like
linting than a refactoring (in case of adding const I can
totally see how that can fit into the general refactoring
pipeline with the “change type of the variable” request, but it
has many pitfalls const-ness change shouldn’t invoke). Both
cases look very much like Clang-Tidy checks to me:</div>
<div class=""><br class="">
</div>
<div class="">* Variable is not mutated anywhere -> change it’s
type to `const T`</div>
</blockquote>
My issue while implementing and thinking about it was, that many
values will not benefit from the clang-tidy transformations because
declarations like `int i, j, k = 0;` and other value-like classes
are common enough. <br>
If only one of these variables can be a constant(e.g. `k`) you can
only emit the warning and can't do the transformation without a
prior 'IsolateDecl'.<br>
<br>
And 'change type' is a common thing for clang-tidy (introducing
smart pointers, auto-usage, gsl::owner, gsl::not_null, ...). All of
them rely to some extend on an 'IsolateDecl'-Refactoring to do their
transformations correct or in more places.<br>
<br>
So I think my main point would be code-reuse. It is possible to
implement these refactoring primitives in the clang-tidy/utils-space
but then other clang-tools could not benefit from it.<br>
<br>
<blockquote type="cite"
cite="mid:FA1AEB65-3048-419E-A1FB-9F422938A5A3@gmail.com">
<div class="">Also, I believe that clang-rename Vim and Emacs
integrations were changed for a long long time (although I can
see that you recently added Python 3 support, thank you!). I
would advise you to use Clangd, which utilises the same
infrastructure Clang-Rename does for renamings, but has way
better support. I understand that setting up Clangd might be not
trivial and I might share my experience soon-ish, so that more
people could try it.</div>
</blockquote>
I honestly did not try it out so far, I have read somewhere that
only Visual Studio is (was?) supported and as a vim on Linux guy I
did not investigate further. I would love to have even more IDE
features and if there is support for vim, I will definitely try it
out (and maybe even help making it better ;)).<br>
<blockquote type="cite"
cite="mid:FA1AEB65-3048-419E-A1FB-9F422938A5A3@gmail.com">
<div class="">To sum up, I would suggest implementing both cases
as Clang-Tidy checks. Right now, Clangd exposes compile warnings
and Fix-Its to the client, so that user can see potentially
problematic places and apply these Fix-Its. AFAIK there is an
ongoing effort to integrate Clang-Tidy into Clangd pipeline so
that Clang-Tidy warnings and Fix-Its would be also exposed to
the user, I am personally very excited about that. Thus said, I
believe you might have way better user experience by going this
way, because you wouldn’t have to implement stand-alone tools
and deal with integration.</div>
</blockquote>
Totally agree that one tool serving all use-cases is best for the
user experience and reducing boilerplate.<br>
<br>
Best Jonas<br>
<blockquote type="cite"
cite="mid:FA1AEB65-3048-419E-A1FB-9F422938A5A3@gmail.com">
<div class=""><br class="">
</div>
<div class="">Let me know if it works for you!</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">Kind regards,</div>
<div class="">Kirill Bobyrev<br class="">
<div><br class="">
</div>
<div>
<div class="">P.S. You can take a look at the original
design: <a
href="https://lists.llvm.org/pipermail/cfe-dev/2016-September/050641.html"
class="" moz-do-not-send="true">https://lists.llvm.org/pipermail/cfe-dev/2016-September/050641.html</a>.
Unfortunately, nothing major happened ever since, but the
idea is still out there, especially now that we have
Clangd.</div>
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 25 Aug 2018, at 11:48, Jonas Toth via
cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org"
class="" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hello everyone,<br class="">
<br class="">
I am currently looking into adding new refactorings
for clang to utilize<br class="">
them both in clang-tidy and clang-refactor.<br
class="">
<br class="">
While exploring clang-refactor it seemed, that the
tool itself does not<br class="">
work yet on standalone files, but only for the
existing test cases. But<br class="">
the code for the tool itself does contain logic to
actually apply<br class="">
refactorings inplace or to print the new file to
stdout.<br class="">
<br class="">
Given that clang-refactor still seems to be in an
unstable stage, could<br class="">
someone point me to the right places to make it work
as standalone tool?<br class="">
I would be very interested to get it running and maybe
write a<br class="">
vim-integration similar to clang-rename as well.<br
class="">
<br class="">
<br class="">
Background:<br class="">
<br class="">
For me it would be very valuable to add the
refactoring to a central<br class="">
place within clang, as I want to extend some of the
clang-tidy checks to<br class="">
do more code transformations which relies sometimes on
prior<br class="">
refactorings. For example to change the const-ness of
a variable it is<br class="">
necessary to isolate the variable declaration first
and change the type<br class="">
second.<br class="">
<br class="">
Transforming `int a, b, c = 0;` into `int a; int b;
int c = 0;` is the<br class="">
refactoring i am implementing at the moment as well.
But my code runs<br class="">
within clang-tidy as I was able to experiment better
with it.<br class="">
<br class="">
<br class="">
Thank you for the help.<br class="">
<br class="">
All the best<br class="">
<br class="">
Jonas<br class="">
<br class="">
_______________________________________________<br
class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" class=""
moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
<br>
</body>
</html>