[cfe-dev] Cross Translation Unit Support in Clang

[Gábor Horváth via cfe-dev]

Hi Noah!

On 28 June 2017 at 19:48, Noah L via cfe-dev <cfe-dev at lists.llvm.org> wrote:

> I think this post refers to the subject of the recent "Cross Translation
> Unit Support in Clang" thread, but I'm not entirely sure I understand the
> issue, so I'll start a new thread rather than potentially pollute that one.
>
> So I've been working on a tool[1], based on libTooling, that automatically
> translates C code to SaferCPlusPlus (essentially, a memory-safe subset of
> C++). The problem I have, if I'm understanding it correctly, is that it can
> only convert one source file (which corresponds to a "translation unit"
> right?) at a time, due to libTooling's  limitation. Right? Does that make
> sense?
>

That is correct. A translation unit is basically a file that is being
compiled and all its dependencies, like headers, precompiled headers,
modules.


>
> Ok, so converting a source file (potentially) modifies the file itself and
> any included header files as well. The problem is when multiple source
> files include the same header file, because conversion of a source file
> requires the included header files to be in their original form. They can't
> have been modified by a previous conversion of another source file. So
> after (individually) converting all the source files in a project, you can
> end up with multiple versions of a header file that were modified in
> different ways by the conversions of different source files. Right? (An
> example[2].)
>

Well, as far as I understand, the idiomatic way to handle this right now,
is not to apply your modifications to the source files right away. First
export all the changes for each translation units into a separate file, and
apply all the changes at once after the tool was run. If all your changes
are consistent, that should work well. If you would transform a header in a
different way in two different translation units that is a problem. I think
the best way to solve that right now to make sure all of your edits are
consistent.


>
> So this means to get the final converted version of the header file you
> have to merge the modifications made by each conversion operation. And
> sometimes the modifications are made on the same line so the merge tool
> can't do the merge automatically. (At least meld doesn't.) This is really
> annoying.
>
> Now, if libTooling were able to operate on the AST of the entire project
> at once this problem would go away. Or if you think the AST of the whole
> project would often be too big, then at least multiple specified
> translation units at a time would help.
>

This is not the usecase this functionality was designed for. I think you
could definitely use it for something like that, but I think the solution I
mentioned above is superior right now. The main use case we wanted to cover
is the ability to gather some information from other translation units that
are required for your tool.


>
> I'm not sure if this is what's being offered in the "Cross Translation
> Unit Support in Clang" thread? I would want the Rewriter::overwriteChangedFiles()
> function to apply to all the source translation units of the AST as well.
>
> Am I making make sense? Feel free to set me straight.
>

I hope I could help.

Regards,
Gábor


>
> Noah
>
> [1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTranslation
> [2] https://github.com/duneroadrunner/SaferCPlusPlus-
> AutoTranslation/tree/master/examples/lodepng
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170629/1065c840/attachment.html>