2021-05-13 13:41:44 +08:00
|
|
|
//===------ Interpreter.cpp - Incremental Compilation and Execution -------===//
|
|
|
|
//
|
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements the component which performs incremental code
|
|
|
|
// compilation and execution.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "clang/Interpreter/Interpreter.h"
|
|
|
|
|
|
|
|
#include "IncrementalExecutor.h"
|
|
|
|
#include "IncrementalParser.h"
|
|
|
|
|
2021-05-21 14:19:10 +08:00
|
|
|
#include "clang/AST/ASTContext.h"
|
2021-05-13 13:41:44 +08:00
|
|
|
#include "clang/Basic/TargetInfo.h"
|
|
|
|
#include "clang/CodeGen/ModuleBuilder.h"
|
|
|
|
#include "clang/CodeGen/ObjectFilePCHContainerOperations.h"
|
|
|
|
#include "clang/Driver/Compilation.h"
|
|
|
|
#include "clang/Driver/Driver.h"
|
|
|
|
#include "clang/Driver/Job.h"
|
|
|
|
#include "clang/Driver/Options.h"
|
|
|
|
#include "clang/Driver/Tool.h"
|
|
|
|
#include "clang/Frontend/CompilerInstance.h"
|
|
|
|
#include "clang/Frontend/TextDiagnosticBuffer.h"
|
|
|
|
#include "clang/Lex/PreprocessorOptions.h"
|
|
|
|
|
|
|
|
#include "llvm/IR/Module.h"
|
|
|
|
#include "llvm/Support/Host.h"
|
|
|
|
|
|
|
|
using namespace clang;
|
|
|
|
|
|
|
|
// FIXME: Figure out how to unify with namespace init_convenience from
|
2021-09-03 21:17:52 +08:00
|
|
|
// tools/clang-import-test/clang-import-test.cpp and
|
|
|
|
// examples/clang-interpreter/main.cpp
|
2021-05-13 13:41:44 +08:00
|
|
|
namespace {
|
|
|
|
/// Retrieves the clang CC1 specific flags out of the compilation's jobs.
|
|
|
|
/// \returns NULL on error.
|
|
|
|
static llvm::Expected<const llvm::opt::ArgStringList *>
|
|
|
|
GetCC1Arguments(DiagnosticsEngine *Diagnostics,
|
|
|
|
driver::Compilation *Compilation) {
|
|
|
|
// We expect to get back exactly one Command job, if we didn't something
|
|
|
|
// failed. Extract that job from the Compilation.
|
|
|
|
const driver::JobList &Jobs = Compilation->getJobs();
|
|
|
|
if (!Jobs.size() || !isa<driver::Command>(*Jobs.begin()))
|
|
|
|
return llvm::createStringError(std::errc::state_not_recoverable,
|
|
|
|
"Driver initialization failed. "
|
|
|
|
"Unable to create a driver job");
|
|
|
|
|
|
|
|
// The one job we find should be to invoke clang again.
|
|
|
|
const driver::Command *Cmd = cast<driver::Command>(&(*Jobs.begin()));
|
|
|
|
if (llvm::StringRef(Cmd->getCreator().getName()) != "clang")
|
|
|
|
return llvm::createStringError(std::errc::state_not_recoverable,
|
|
|
|
"Driver initialization failed");
|
|
|
|
|
|
|
|
return &Cmd->getArguments();
|
|
|
|
}
|
|
|
|
|
|
|
|
static llvm::Expected<std::unique_ptr<CompilerInstance>>
|
|
|
|
CreateCI(const llvm::opt::ArgStringList &Argv) {
|
|
|
|
std::unique_ptr<CompilerInstance> Clang(new CompilerInstance());
|
|
|
|
IntrusiveRefCntPtr<DiagnosticIDs> DiagID(new DiagnosticIDs());
|
|
|
|
|
|
|
|
// Register the support for object-file-wrapped Clang modules.
|
|
|
|
// FIXME: Clang should register these container operations automatically.
|
|
|
|
auto PCHOps = Clang->getPCHContainerOperations();
|
|
|
|
PCHOps->registerWriter(std::make_unique<ObjectFilePCHContainerWriter>());
|
|
|
|
PCHOps->registerReader(std::make_unique<ObjectFilePCHContainerReader>());
|
|
|
|
|
|
|
|
// Buffer diagnostics from argument parsing so that we can output them using
|
|
|
|
// a well formed diagnostic object.
|
|
|
|
IntrusiveRefCntPtr<DiagnosticOptions> DiagOpts = new DiagnosticOptions();
|
|
|
|
TextDiagnosticBuffer *DiagsBuffer = new TextDiagnosticBuffer;
|
|
|
|
DiagnosticsEngine Diags(DiagID, &*DiagOpts, DiagsBuffer);
|
|
|
|
bool Success = CompilerInvocation::CreateFromArgs(
|
|
|
|
Clang->getInvocation(), llvm::makeArrayRef(Argv.begin(), Argv.size()),
|
|
|
|
Diags);
|
|
|
|
|
|
|
|
// Infer the builtin include path if unspecified.
|
|
|
|
if (Clang->getHeaderSearchOpts().UseBuiltinIncludes &&
|
|
|
|
Clang->getHeaderSearchOpts().ResourceDir.empty())
|
|
|
|
Clang->getHeaderSearchOpts().ResourceDir =
|
|
|
|
CompilerInvocation::GetResourcesPath(Argv[0], nullptr);
|
|
|
|
|
|
|
|
// Create the actual diagnostics engine.
|
|
|
|
Clang->createDiagnostics();
|
|
|
|
if (!Clang->hasDiagnostics())
|
|
|
|
return llvm::createStringError(std::errc::state_not_recoverable,
|
|
|
|
"Initialization failed. "
|
|
|
|
"Unable to create diagnostics engine");
|
|
|
|
|
|
|
|
DiagsBuffer->FlushDiagnostics(Clang->getDiagnostics());
|
|
|
|
if (!Success)
|
|
|
|
return llvm::createStringError(std::errc::state_not_recoverable,
|
|
|
|
"Initialization failed. "
|
|
|
|
"Unable to flush diagnostics");
|
|
|
|
|
|
|
|
// FIXME: Merge with CompilerInstance::ExecuteAction.
|
|
|
|
llvm::MemoryBuffer *MB = llvm::MemoryBuffer::getMemBuffer("").release();
|
|
|
|
Clang->getPreprocessorOpts().addRemappedFile("<<< inputs >>>", MB);
|
|
|
|
|
|
|
|
Clang->setTarget(TargetInfo::CreateTargetInfo(
|
|
|
|
Clang->getDiagnostics(), Clang->getInvocation().TargetOpts));
|
|
|
|
if (!Clang->hasTarget())
|
|
|
|
return llvm::createStringError(std::errc::state_not_recoverable,
|
|
|
|
"Initialization failed. "
|
|
|
|
"Target is missing");
|
|
|
|
|
2021-06-29 23:44:49 +08:00
|
|
|
Clang->getTarget().adjust(Clang->getDiagnostics(), Clang->getLangOpts());
|
2021-05-13 13:41:44 +08:00
|
|
|
|
|
|
|
return std::move(Clang);
|
|
|
|
}
|
|
|
|
|
|
|
|
} // anonymous namespace
|
|
|
|
|
|
|
|
llvm::Expected<std::unique_ptr<CompilerInstance>>
|
|
|
|
IncrementalCompilerBuilder::create(std::vector<const char *> &ClangArgv) {
|
|
|
|
|
|
|
|
// If we don't know ClangArgv0 or the address of main() at this point, try
|
|
|
|
// to guess it anyway (it's possible on some platforms).
|
|
|
|
std::string MainExecutableName =
|
|
|
|
llvm::sys::fs::getMainExecutable(nullptr, nullptr);
|
|
|
|
|
|
|
|
ClangArgv.insert(ClangArgv.begin(), MainExecutableName.c_str());
|
|
|
|
|
|
|
|
// Prepending -c to force the driver to do something if no action was
|
|
|
|
// specified. By prepending we allow users to override the default
|
|
|
|
// action and use other actions in incremental mode.
|
|
|
|
// FIXME: Print proper driver diagnostics if the driver flags are wrong.
|
|
|
|
ClangArgv.insert(ClangArgv.begin() + 1, "-c");
|
|
|
|
|
|
|
|
if (!llvm::is_contained(ClangArgv, " -x")) {
|
|
|
|
// We do C++ by default; append right after argv[0] if no "-x" given
|
|
|
|
ClangArgv.push_back("-x");
|
|
|
|
ClangArgv.push_back("c++");
|
|
|
|
}
|
|
|
|
|
|
|
|
// Put a dummy C++ file on to ensure there's at least one compile job for the
|
|
|
|
// driver to construct.
|
|
|
|
ClangArgv.push_back("<<< inputs >>>");
|
|
|
|
|
|
|
|
CompilerInvocation Invocation;
|
|
|
|
// Buffer diagnostics from argument parsing so that we can output them using a
|
|
|
|
// well formed diagnostic object.
|
|
|
|
IntrusiveRefCntPtr<DiagnosticIDs> DiagID(new DiagnosticIDs());
|
2021-08-30 21:41:53 +08:00
|
|
|
IntrusiveRefCntPtr<DiagnosticOptions> DiagOpts =
|
|
|
|
CreateAndPopulateDiagOpts(ClangArgv);
|
2021-05-13 13:41:44 +08:00
|
|
|
TextDiagnosticBuffer *DiagsBuffer = new TextDiagnosticBuffer;
|
|
|
|
DiagnosticsEngine Diags(DiagID, &*DiagOpts, DiagsBuffer);
|
|
|
|
|
|
|
|
driver::Driver Driver(/*MainBinaryName=*/ClangArgv[0],
|
2021-05-19 01:53:54 +08:00
|
|
|
llvm::sys::getProcessTriple(), Diags);
|
2021-05-13 13:41:44 +08:00
|
|
|
Driver.setCheckInputsExist(false); // the input comes from mem buffers
|
|
|
|
llvm::ArrayRef<const char *> RF = llvm::makeArrayRef(ClangArgv);
|
|
|
|
std::unique_ptr<driver::Compilation> Compilation(Driver.BuildCompilation(RF));
|
|
|
|
|
|
|
|
if (Compilation->getArgs().hasArg(driver::options::OPT_v))
|
|
|
|
Compilation->getJobs().Print(llvm::errs(), "\n", /*Quote=*/false);
|
|
|
|
|
|
|
|
auto ErrOrCC1Args = GetCC1Arguments(&Diags, Compilation.get());
|
|
|
|
if (auto Err = ErrOrCC1Args.takeError())
|
|
|
|
return std::move(Err);
|
|
|
|
|
|
|
|
return CreateCI(**ErrOrCC1Args);
|
|
|
|
}
|
|
|
|
|
|
|
|
Interpreter::Interpreter(std::unique_ptr<CompilerInstance> CI,
|
|
|
|
llvm::Error &Err) {
|
|
|
|
llvm::ErrorAsOutParameter EAO(&Err);
|
|
|
|
auto LLVMCtx = std::make_unique<llvm::LLVMContext>();
|
|
|
|
TSCtx = std::make_unique<llvm::orc::ThreadSafeContext>(std::move(LLVMCtx));
|
|
|
|
IncrParser = std::make_unique<IncrementalParser>(std::move(CI),
|
|
|
|
*TSCtx->getContext(), Err);
|
|
|
|
}
|
|
|
|
|
|
|
|
Interpreter::~Interpreter() {}
|
|
|
|
|
|
|
|
llvm::Expected<std::unique_ptr<Interpreter>>
|
|
|
|
Interpreter::create(std::unique_ptr<CompilerInstance> CI) {
|
|
|
|
llvm::Error Err = llvm::Error::success();
|
|
|
|
auto Interp =
|
|
|
|
std::unique_ptr<Interpreter>(new Interpreter(std::move(CI), Err));
|
|
|
|
if (Err)
|
|
|
|
return std::move(Err);
|
|
|
|
return std::move(Interp);
|
|
|
|
}
|
|
|
|
|
|
|
|
const CompilerInstance *Interpreter::getCompilerInstance() const {
|
|
|
|
return IncrParser->getCI();
|
|
|
|
}
|
|
|
|
|
Reland "[clang-repl] Implement partial translation units and error recovery."
Original commit message:
[clang-repl] Implement partial translation units and error recovery.
https://reviews.llvm.org/D96033 contained a discussion regarding efficient
modeling of error recovery. @rjmccall has outlined the key ideas:
Conceptually, we can split the translation unit into a sequence of partial
translation units (PTUs). Every declaration will be associated with a unique PTU
that owns it.
The first key insight here is that the owning PTU isn't always the "active"
(most recent) PTU, and it isn't always the PTU that the declaration
"comes from". A new declaration (that isn't a redeclaration or specialization of
anything) does belong to the active PTU. A template specialization, however,
belongs to the most recent PTU of all the declarations in its signature - mostly
that means that it can be pulled into a more recent PTU by its template
arguments.
The second key insight is that processing a PTU might extend an earlier PTU.
Rolling back the later PTU shouldn't throw that extension away. For example, if
the second PTU defines a template, and the third PTU requires that template to
be instantiated at float, that template specialization is still part of the
second PTU. Similarly, if the fifth PTU uses an inline function belonging to the
fourth, that definition still belongs to the fourth. When we go to emit code in
a new PTU, we map each declaration we have to emit back to its owning PTU and
emit it in a new module for just the extensions to that PTU. We keep track of
all the modules we've emitted for a PTU so that we can unload them all if we
decide to roll it back.
Most declarations/definitions will only refer to entities from the same or
earlier PTUs. However, it is possible (primarily by defining a
previously-declared entity, but also through templates or ADL) for an entity
that belongs to one PTU to refer to something from a later PTU. We will have to
keep track of this and prevent unwinding to later PTU when we recognize it.
Fortunately, this should be very rare; and crucially, we don't have to do the
bookkeeping for this if we've only got one PTU, e.g. in normal compilation.
Otherwise, PTUs after the first just need to record enough metadata to be able
to revert any changes they've made to declarations belonging to earlier PTUs,
e.g. to redeclaration chains or template specialization lists.
It should even eventually be possible for PTUs to provide their own slab
allocators which can be thrown away as part of rolling back the PTU. We can
maintain a notion of the active allocator and allocate things like Stmt/Expr
nodes in it, temporarily changing it to the appropriate PTU whenever we go to do
something like instantiate a function template. More care will be required when
allocating declarations and types, though.
We would want the PTU to be efficiently recoverable from a Decl; I'm not sure
how best to do that. An easy option that would cover most declarations would be
to make multiple TranslationUnitDecls and parent the declarations appropriately,
but I don't think that's good enough for things like member function templates,
since an instantiation of that would still be parented by its original class.
Maybe we can work this into the DC chain somehow, like how lexical DCs are.
We add a different kind of translation unit `TU_Incremental` which is a
complete translation unit that we might nonetheless incrementally extend later.
Because it is complete (and we might want to generate code for it), we do
perform template instantiation, but because it might be extended later, we don't
warn if it declares or uses undefined internal-linkage symbols.
This patch teaches clang-repl how to recover from errors by disconnecting the
most recent PTU and update the primary PTU lookup tables. For instance:
```./clang-repl
clang-repl> int i = 12; error;
In file included from <<< inputs >>>:1:
input_line_0:1:13: error: C++ requires a type specifier for all declarations
int i = 12; error;
^
error: Parsing failed.
clang-repl> int i = 13; extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=13
clang-repl> quit
```
Differential revision: https://reviews.llvm.org/D104918
2021-07-12 21:35:20 +08:00
|
|
|
llvm::Expected<PartialTranslationUnit &>
|
|
|
|
Interpreter::Parse(llvm::StringRef Code) {
|
2021-05-13 13:41:44 +08:00
|
|
|
return IncrParser->Parse(Code);
|
|
|
|
}
|
|
|
|
|
Reland "[clang-repl] Implement partial translation units and error recovery."
Original commit message:
[clang-repl] Implement partial translation units and error recovery.
https://reviews.llvm.org/D96033 contained a discussion regarding efficient
modeling of error recovery. @rjmccall has outlined the key ideas:
Conceptually, we can split the translation unit into a sequence of partial
translation units (PTUs). Every declaration will be associated with a unique PTU
that owns it.
The first key insight here is that the owning PTU isn't always the "active"
(most recent) PTU, and it isn't always the PTU that the declaration
"comes from". A new declaration (that isn't a redeclaration or specialization of
anything) does belong to the active PTU. A template specialization, however,
belongs to the most recent PTU of all the declarations in its signature - mostly
that means that it can be pulled into a more recent PTU by its template
arguments.
The second key insight is that processing a PTU might extend an earlier PTU.
Rolling back the later PTU shouldn't throw that extension away. For example, if
the second PTU defines a template, and the third PTU requires that template to
be instantiated at float, that template specialization is still part of the
second PTU. Similarly, if the fifth PTU uses an inline function belonging to the
fourth, that definition still belongs to the fourth. When we go to emit code in
a new PTU, we map each declaration we have to emit back to its owning PTU and
emit it in a new module for just the extensions to that PTU. We keep track of
all the modules we've emitted for a PTU so that we can unload them all if we
decide to roll it back.
Most declarations/definitions will only refer to entities from the same or
earlier PTUs. However, it is possible (primarily by defining a
previously-declared entity, but also through templates or ADL) for an entity
that belongs to one PTU to refer to something from a later PTU. We will have to
keep track of this and prevent unwinding to later PTU when we recognize it.
Fortunately, this should be very rare; and crucially, we don't have to do the
bookkeeping for this if we've only got one PTU, e.g. in normal compilation.
Otherwise, PTUs after the first just need to record enough metadata to be able
to revert any changes they've made to declarations belonging to earlier PTUs,
e.g. to redeclaration chains or template specialization lists.
It should even eventually be possible for PTUs to provide their own slab
allocators which can be thrown away as part of rolling back the PTU. We can
maintain a notion of the active allocator and allocate things like Stmt/Expr
nodes in it, temporarily changing it to the appropriate PTU whenever we go to do
something like instantiate a function template. More care will be required when
allocating declarations and types, though.
We would want the PTU to be efficiently recoverable from a Decl; I'm not sure
how best to do that. An easy option that would cover most declarations would be
to make multiple TranslationUnitDecls and parent the declarations appropriately,
but I don't think that's good enough for things like member function templates,
since an instantiation of that would still be parented by its original class.
Maybe we can work this into the DC chain somehow, like how lexical DCs are.
We add a different kind of translation unit `TU_Incremental` which is a
complete translation unit that we might nonetheless incrementally extend later.
Because it is complete (and we might want to generate code for it), we do
perform template instantiation, but because it might be extended later, we don't
warn if it declares or uses undefined internal-linkage symbols.
This patch teaches clang-repl how to recover from errors by disconnecting the
most recent PTU and update the primary PTU lookup tables. For instance:
```./clang-repl
clang-repl> int i = 12; error;
In file included from <<< inputs >>>:1:
input_line_0:1:13: error: C++ requires a type specifier for all declarations
int i = 12; error;
^
error: Parsing failed.
clang-repl> int i = 13; extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=13
clang-repl> quit
```
Differential revision: https://reviews.llvm.org/D104918
2021-07-12 21:35:20 +08:00
|
|
|
llvm::Error Interpreter::Execute(PartialTranslationUnit &T) {
|
2021-05-13 13:41:44 +08:00
|
|
|
assert(T.TheModule);
|
|
|
|
if (!IncrExecutor) {
|
2021-05-21 14:19:10 +08:00
|
|
|
const llvm::Triple &Triple =
|
|
|
|
getCompilerInstance()->getASTContext().getTargetInfo().getTriple();
|
2021-05-13 13:41:44 +08:00
|
|
|
llvm::Error Err = llvm::Error::success();
|
2021-05-21 14:19:10 +08:00
|
|
|
IncrExecutor = std::make_unique<IncrementalExecutor>(*TSCtx, Err, Triple);
|
|
|
|
|
2021-05-13 13:41:44 +08:00
|
|
|
if (Err)
|
|
|
|
return Err;
|
|
|
|
}
|
|
|
|
// FIXME: Add a callback to retain the llvm::Module once the JIT is done.
|
|
|
|
if (auto Err = IncrExecutor->addModule(std::move(T.TheModule)))
|
|
|
|
return Err;
|
|
|
|
|
|
|
|
if (auto Err = IncrExecutor->runCtors())
|
|
|
|
return Err;
|
|
|
|
|
|
|
|
return llvm::Error::success();
|
|
|
|
}
|