[cfe-dev] Builtin headers

[Benjamin Kramer via cfe-dev]

On Thu, Feb 4, 2016 at 3:42 PM, Mikhail Ramalho via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> Hi Manuel and Benjamin,
>
> Is this available on clang 3.8? (I'm building clang 3.8 now to try it out)

Yep, this is new in 3.8.

> Is it too much trouble if you could provide some example? Do you simply add
> code from builtin headers content and map to a virtual file with the same
> name?

The basic idea is to create a vfs::OverlayFileSystem with both a
vfs::RealFileSystem and a vfs::InMemoryFileSystem, and add the builtin
headers at a virtual path in the InMemoryFileSystem. Then initialize
your FileManager with the OverlayFileSystem and everything should
work.

There should be some example of this in-tree, just grep for InMemoryFileSystem.

> 2016-02-02 16:13 GMT+00:00 Manuel Klimek <klimek at google.com>:
>>
>> Benjamin has added virtual fs capabilities that should enable us to be
>> virtually overlay the builtin headers while still doing a normal header
>> search (we are successfully doing that).
>>
>> On Tue, Feb 2, 2016 at 4:58 PM Mikhail Ramalho via cfe-dev
>> <cfe-dev at lists.llvm.org> wrote:
>>>
>>> Hello all,
>>>
>>> I'm using clang as a frontend to parse C and C++ code, which I convert to
>>> an internal format that my tool understand.
>>>
>>> Since the beginning of the development, there was the problem including
>>> the builtin headers to the compilation which I kinda fix with a code to
>>> search for headers on the system.
>>>
>>> The problem is that we ship the binary, including static and dynamic
>>> versions, which requires that the users to have clang installed on their
>>> machines. It's OK for the dynamic version but for the static one it's a bad
>>> solution.
>>>
>>> So, right now I only found this two solutions:
>>>
>>> 1. Either the user must have clang installed in their machines (which I
>>> can't tell if there will be a problem about using headers from different
>>> versions of clang).
>>>
>>> 2. Ship all the builtin headers, even for the static version, and hard
>>> code a path for them from the binary (like clang does).
>>>
>>> Is it possible to implement a third solution: circumvent the requirement
>>> for all the builtin headers? I even tried to copy the builitin headers as
>>> virtualFiles, but it doesn't work.
>>>
>>> I'm using the following code to generate the AST:
>>>
>>> bool llvm_languaget::parse(const std::string& path)
>>> {
>>>   // Finish the compiler string
>>>   std::vector<std::string> compiler_string;
>>>   build_compiler_string(compiler_string);
>>>
>>>   clang::tooling::FixedCompilationDatabase Compilations("./",
>>> compiler_string);
>>>
>>>   std::vector<std::string> sources;
>>>   sources.push_back("/esbmc_intrinsics.h");
>>>   sources.push_back(path);
>>>
>>>   clang::tooling::ClangTool Tool(Compilations, sources);
>>>   Tool.mapVirtualFile("/esbmc_intrinsics.h", intrinsics);
>>>
>>>   Tool.buildASTs(ASTs);
>>>
>>>   // Use diagnostics to find errors, rather than the return code.
>>>   for (const auto &astunit : ASTs) {
>>>     if (astunit->getDiagnostics().hasErrorOccurred()) {
>>>       std::cerr << std::endl;
>>>       return true;
>>>     }
>>>   }
>>>
>>>   return false;
>>> }
>>>
>>> I already use VirtualFile to map some variables and function declarations
>>> but it doesn't work if add, for example, the code from stddef.h and map to a
>>> virtual stddef.h.
>>>
>>> Thank you,
>>>
>>> --
>>>
>>> Mikhail Ramalho.
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
>
> --
>
> Mikhail Ramalho.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>