[llvm-dev] [GSoC 2017] Clang-based diff tool project

[Alex L via llvm-dev]

On 21 March 2017 at 21:44, Johannes Altmanninger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> So I have been playing around with this some more.
>
> > Yes. But we developed software as libraries usually. Practically I
> > expect the main part of the work to write some piece of API that
> > generate an “in-memory” representation of the diff.
>
> Yes, of course, I think the representation will be just a set of
> changes, where a change is a insert/update/removal of a node.
>
> > In the future I hope it’d enable other graphical diff client to
> > plug-in, or git-merge resolution tools as well.
> Yes, merge tools would be a nice application for this, as Hal also
> pointed out. Of course it is easy to make the output machine readable or
> just use the API in the first place.
>
> Unfortunately it is not possible to (de-)serialize the AST from/to XML
> (or some other structured data format). If it was, one could use
> existing structural diff tools to make prototypes or help test the final
> version.
>
> I have another question as I have never written a clang tool before: One
> could use LibClang or LibTooling, the former seems easier and probably
> good enough (?)
>

Hi Johannes,
I think a tool like this should use LibTooling directly since libclang does
not expose all of the information that's present in the AST.
Alex


>
> Furthermore, should I work on a small patch / fix an easy bug to show
> that I am comfortable with the development process? I am a bit lost with
> the bug tracker, so if you can suggest things to work I will try that.
> Other than that I can work on a prototype for the tool but that takes
> some time.  I found one small typo in clang, I guess I could submit
> that..
>
> Johannes
>
>
> diff --git a/include/clang/AST/RecursiveASTVisitor.h b/include/clang/AST/
> RecursiveASTVisitor.h
> index 1b5850a05b..c31e4b0bb4 100644
> --- a/include/clang/AST/RecursiveASTVisitor.h
> +++ b/include/clang/AST/RecursiveASTVisitor.h
> @@ -83,7 +83,7 @@ namespace clang {
>        return false;
>       \
>    } while (false)
>
> -/// \brief A class that does preordor or postorder
> +/// \brief A class that does preorder or postorder
>  /// depth-first traversal on the entire Clang AST and visits each node.
>  ///
>  /// This class performs three distinct tasks:
>
>
>
> Mehdi Amini <mehdi.amini at apple.com> writes:
>
> > (+CC: Greg Clayton who gave me this idea in the first place)
> >
> >> On Mar 20, 2017, at 3:20 PM, Johannes Altmanninger via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>
> >> Hello,
> >>
> >> I am currently studying Computer Science at TU Eindhoven. I am doing a
> >> course that involves programming assignments on parts of LLVM such as
> >> lowering, scheduling and optimization. For this year's Google Summer of
> >> Code I plan to submit a proposal to implement a clang-based diff tool
> >> [1].
> >
> > Great! I look forward to see this :)
> >
> >>
> >> I think it really pays off to have decent developer tools available, as
> >> they can save tons of time. Clang tooling has obviously been very
> >> successful.  I think it would be a good idea to develop a diff tool that
> >> considers the structure of the code, as opposed to just the lines. Plain
> >> old diff only thinks in terms of "additions" and "deletions", although
> >> it would be more natural to also consider "updates" and "moves".
> >>
> >> So a structural diff would work solely on the AST, hence formatting
> >> changes are ignored. It would allow to highlight the exact location of a
> >> change, and not a whole line. Furthermore, it would allow to compare
> >> pieces of code with the same structure (think subclasses).
> >>
> >> Besides some papers with clever AST-matching algorithms, a quick web
> >> search yielded [2], which is a proof-of-concept implementation of a
> >> structural comparison algorithm.  I think it demonstrates rather nicely
> >> what could be done: movement of chunks of code can be easily traced.
> >>
> >> Anyway, one could make all kinds of nice visualizations using a AST diff
> >> tool, however, I think the initial focus should probably be on creating
> >> one with a similar output to traditional diff, with the difference that
> >> updates and moves are displayed in a easily readable way, which already
> >> could improve developer productivity and happiness.
> >>
> >> As of now I have one question: The output of the tool is meant just for
> >> humans to read (and not for actual patching), right?
> >
> > Yes. But we developed software as libraries usually. Practically I
> expect the main part of the work to write some piece of API that generate
> an “in-memory” representation of the diff.
> >
> > A tool that is generating a textual-human readable output is likely the
> first client of this API and is likely critical to be able to functionally
> test it in the early development. In the future I hope it’d enable other
> graphical diff client to plug-in, or git-merge resolution tools as well.
> >
> > Best,
> >
> > —
> > Mehdi
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170331/259ec1af/attachment.html>