Circumventing ExecuteAction's initialization of SourceManager instance

Clang Frontend
1

Is there anyway around FrontendAction::Execute(...)'s use of CompilerInstance::
InitializeSourceManager(...)?

I'm trying to switch from using ParseAST to CompilerInstance::ExecuteAction when
operating on memory buffers initialized with a code string. The eventually called
FrontendAction::Execute implementation hangs on a lower MemoryBuffer::getSTDIN(...)
read, but would subsequently fail anyway when trying to reinitialized the
the SourceManager instance. I know the doc for CompilerInstance::ExecuteAction
specifically states that the supplied SourceManager should not be pre-initialized, but
I know of no other way to use memory buffers directly.

In detail:

I setup my source manager via:

    compInst.createFileManager();
    compInst.createSourceManager(compInst.getFileManager(),
                                 compInst.getFileSystemOpts());
    compInst.getSourceManager().createMainFileIDForMemBuffer(buffer);

compInst is a CompilerInstance, and buffer is previously setup with:

    const char * src = codeString.data();
    llvm::StringRef input_data(src);
    llvm::StringRef buffer_name("src");
    llvm::MemoryBuffer *buffer =
        llvm::MemoryBuffer::getMemBufferCopy(input_data, buffer_name);

I then invoke the action code path with:

    llvm::OwningPtr<clang::SyntaxOnlyAction> act(new MyASTAction);

    if (compInst.ExecuteAction(*act))
    {
    ....

I looked for overwriting opportunities, but CompilerInstance::InitializeSourceManager
is static, and FrontendAction::Execute is non-virtual. If there is not another way to use
the CompilerInstance::ExecuteAction code path with memory buffers, would it be ok
to patch CompilerInstance::InitializeSourceManager to only do its SourceManager
initializations if its MainFileID is invalid? Beyond violating the contract as indicated
by the CompilerInstance::ExecuteAction doc, I don't know what other effects this
would have.

... and there always is "I don't understand the code correctly" so feel free to jump in. :slight_smile:

Thanks in advance

Garrison

2

Hi Garrison,

The way I handle this is to use PreprocessorOpts::addRemappedFile to
set up a mapping from a source code "file" name to the memory buffer
(which is really a dummy file name that shows up in diagnostics etc).
I then add that name to the input list. You can see my source
code here:

http://git.pcc.me.uk/?p=~peter/klee-fp.git;a=blob;f=lib/Core/SpecialFunctionHandler.cpp;h=12366319f85110634e2267ddb221050485b4e717;hb=HEAD#l815
(in particular lines 815-816 and 818)

Thanks,

3

Cool! Appreciate the help.

Garrison

4

FYI, in trunk it looks like they got rid of CompilerInvocation::setLangDefaults, and
replaced your usage with:

(CI->getLangOpts()).OpenCL = 1;

Thanks again, the code mod motivated by your code worked great.

Garrison

5

Hi Garrison,

Actually, setting OpenCL to 1 won't work on its own; there are a number
of other flags that need to be set. setLangDefaults is part of a patch
[1] I sent to cfe-commits which is meant to make this use case easier
to handle. I'm still waiting for feedback on the patch (hint...)

Thanks,

6

That would be a nice simplification, although I did not look at the results of the patch
just the patch file. I went git about a month ago for a non LLVM project, so I think
when I have time I'll use your patch in a git version. Although I know that svn can work
with git, and people have publicly available git repos, I've been nervous about
mixing the two. I guess there are no issues when submitting patches?

Garrison

7

That would be a nice simplification, although I did not look at the results of the patch
just the patch file. I went git about a month ago for a non LLVM project, so I think
when I have time I'll use your patch in a git version. Although I know that svn can work
with git, and people have publicly available git repos, I've been nervous about
mixing the two. I guess there are no issues when submitting patches?

Hi Garrison,

There are a number of git mirrors of the LLVM and Clang repositories
around, which I've used without issue to keep up to date with trunk.

Git produces standard diff format patches so you should be able to
apply the patch using "patch -p1". This also makes things easier
for reviewers who might not be using git.

I'll apply the patch to trunk in a week unless there is an objection,
so you shouldn't need to apply it yourself unless you want to.

Thanks,

--

Peter