Commit Graph

45 Commits

Author SHA1 Message Date
Vassil Vassilev 575e297fcb Revert "[clang-repl] Recover the lookup tables of the primary context."
This reverts commit 5ff27fe1ff.

This patch caused failures in asan: https://lab.llvm.org/buildbot/#/builders/5/builds/24221
2022-05-31 06:25:37 +00:00
Purva-Chaudhari 5ff27fe1ff [clang-repl] Recover the lookup tables of the primary context.
Before this patch, there was re-declaration error if error was encountered in
the same line. The recovery support acted only if this type of error was
encountered in the first line of the program and not in subsequent lines.

For example:

```
clang-repl> int i=9;
clang-repl> int j=9; err;
input_line_3:1:5: error: redefinition of 'j'
int j = 9;
```

Differential revision: https://reviews.llvm.org/D123674
2022-05-29 04:59:40 +00:00
Lang Hames 16dcbb53dc [ORC] Return ExecutorAddrs rather than JITEvaluatedSymbols from LLJIT::lookup.
Clients don't care about linkage, and ExecutorAddr is much more ergonomic.
2022-05-05 13:56:00 -07:00
Vassil Vassilev 788e0f7f3e [clang-repl] Add an accessor to our underlying execution engine
This patch will allow better incremental adoption of these changes in downstream
cling and other users which want to experiment by customizing the execution
engine.
2022-03-11 09:24:47 +00:00
Iain Sandoe ab28488efe [C++20][Modules][1/8] Track valid import state.
In C++20 modules imports must be together and at the start of the module.
Rather than growing more ad-hoc flags to test state, this keeps track of the
phase of of a valid module TU (first decl, global module frag, module,
private module frag).  If the phasing is broken (with some diagnostic) the
pattern does not conform to a valid C++20 module, and we set the state
accordingly.

We can thus issue diagnostics when imports appear in the wrong places and
decouple the C++20 modules state from other module variants (modules-ts and
clang modules).  Additionally, we attempt to diagnose wrong imports before
trying to find the module where possible (the latter will generally emit an
unhelpful diagnostic about the module not being available).

Although this generally simplifies the handling of C++20 module import
diagnostics, the motivation was that, in particular, it allows detecting
invalid imports like:

import module A;

int some_decl();

import module B;

where being in a module purview is insufficient to identify them.

Differential Revision: https://reviews.llvm.org/D118893
2022-02-21 09:09:37 +00:00
Iain Sandoe 673879249d Revert "[C++20][Modules][1/8] Track valid import state."
This reverts commit 8a3f9a584a.

need to investigate build failures that do not show on CI or local
testing.
2022-02-20 10:22:07 +00:00
Iain Sandoe 8a3f9a584a [C++20][Modules][1/8] Track valid import state.
In C++20 modules imports must be together and at the start of the module.
Rather than growing more ad-hoc flags to test state, this keeps track of the
phase of of a valid module TU (first decl, global module frag, module,
private module frag).  If the phasing is broken (with some diagnostic) the
pattern does not conform to a valid C++20 module, and we set the state
accordingly.

We can thus issue diagnostics when imports appear in the wrong places and
decouple the C++20 modules state from other module variants (modules-ts and
clang modules).  Additionally, we attempt to diagnose wrong imports before
trying to find the module where possible (the latter will generally emit an
unhelpful diagnostic about the module not being available).

Although this generally simplifies the handling of C++20 module import
diagnostics, the motivation was that, in particular, it allows detecting
invalid imports like:

import module A;

int some_decl();

import module B;

where being in a module purview is insufficient to identify them.

Differential Revision: https://reviews.llvm.org/D118893
2022-02-20 10:13:57 +00:00
Kazu Hirata d1b127b5b7 [clang] Remove unused forward declarations (NFC) 2022-01-08 11:56:40 -08:00
Kazu Hirata 298367ee6e [clang] Use nullptr instead of 0 or NULL (NFC)
Identified with modernize-use-nullptr.
2021-12-29 08:34:20 -08:00
Vassil Vassilev 4fb0805c65 [clang-repl] Allow Interpreter::getSymbolAddress to take a mangled name. 2021-11-10 12:52:05 +00:00
Vassil Vassilev c24a58081b Reinstate "[clang-repl] Re-implement clang-interpreter as a test case."
Original commit message: "
  Original commit message: "
    Original commit message: "
       Original commit message:"
         The current infrastructure in lib/Interpreter has a tool, clang-repl, very
         similar to clang-interpreter which also allows incremental compilation.

         This patch moves clang-interpreter as a test case and drops it as conditionally
         built example as we already have clang-repl in place.
       "

       This patch also ignores ppc due to missing weak symbol for __gxx_personality_v0
       which may be a feature request for the jit infrastructure. Also, adds a missing
       build system dependency to the orc jit.
    "

    Additionally, this patch defines a custom exception type and thus avoids the
    requirement to include header <exception>, making it easier to deploy across
    systems without standard location of the c++ headers.
  "

  This patch also works around PR49692 and finds a way to use llvm::consumeError
  in rtti mode.
"

This patch also checks if stl is built with rtti.

Differential revision: https://reviews.llvm.org/D107049
2021-10-26 19:29:56 +00:00
Arthur Eubanks 19b07ec000 Reland [clang] Pass -clear-ast-before-backend in Clang::ConstructJob()
This clears the memory used for the Clang AST before we run LLVM passes.

https://llvm-compile-time-tracker.com/compare.php?from=d0a5f61c4f6fccec87fd5207e3fcd9502dd59854&to=b7437fee79e04464dd968e1a29185495f3590481&stat=max-rss
shows significant memory savings with no slowdown (in fact -O0 slightly speeds up).

For more background, see
https://lists.llvm.org/pipermail/cfe-dev/2021-September/068930.html.

Turn this off for the interpreter since it does codegen multiple times.

Relanding with fix for -print-stats: D111973

Relanding with fix for plugins: D112190

If you'd like to use this even with plugins, consider using the features
introduced in D112096.

This can be turned off with -Xclang -no-clear-ast-before-backend.

Differential Revision: https://reviews.llvm.org/D111270
2021-10-21 09:25:53 -07:00
Zequan Wu 57553ce432 Revert "Reland [clang] Pass -clear-ast-before-backend in Clang::ConstructJob()"
This reverts commit 1fb24fe85a.

This causes clang crash on chromium. See repro at https://bugs.chromium.org/p/chromium/issues/detail?id=1261551#c1.
2021-10-19 12:39:34 -07:00
Arthur Eubanks 1fb24fe85a Reland [clang] Pass -clear-ast-before-backend in Clang::ConstructJob()
This clears the memory used for the Clang AST before we run LLVM passes.

https://llvm-compile-time-tracker.com/compare.php?from=d0a5f61c4f6fccec87fd5207e3fcd9502dd59854&to=b7437fee79e04464dd968e1a29185495f3590481&stat=max-rss
shows significant memory savings with no slowdown (in fact -O0 slightly speeds up).

For more background, see
https://lists.llvm.org/pipermail/cfe-dev/2021-September/068930.html.

Turn this off for the interpreter since it does codegen multiple times.

Relanding with fix for -print-stats: D111973

Differential Revision: https://reviews.llvm.org/D111270
2021-10-18 09:08:16 -07:00
Arthur Eubanks 49562d3dfe Revert "[clang] Pass -clear-ast-before-backend in Clang::ConstructJob()"
This reverts commit 47eb99aa44.

This causes crashes with -print-stats: PR52193.
2021-10-16 12:05:41 -07:00
Arthur Eubanks 47eb99aa44 [clang] Pass -clear-ast-before-backend in Clang::ConstructJob()
This clears the memory used for the Clang AST before we run LLVM passes.

https://llvm-compile-time-tracker.com/compare.php?from=d0a5f61c4f6fccec87fd5207e3fcd9502dd59854&to=b7437fee79e04464dd968e1a29185495f3590481&stat=max-rss
shows significant memory savings with no slowdown (in fact -O0 slightly speeds up).

For more background, see
https://lists.llvm.org/pipermail/cfe-dev/2021-September/068930.html.

Turn this off for the interpreter since it does codegen multiple times.

Differential Revision: https://reviews.llvm.org/D111270
2021-10-15 10:13:17 -07:00
Arthur Eubanks 675ed4c82d [NFC][Interpreter] Remove unused CompilerInvocation 2021-10-14 15:17:49 -07:00
Leonard Chan 04aff39504 Revert "Reland "[clang-repl] Re-implement clang-interpreter as a test case.""
This reverts commit 1dba6b37bd.

Reverting because the ClangReplInterpreterExceptionTests test fails on
our builders with this patch.
2021-10-08 17:43:23 -07:00
Vassil Vassilev 1dba6b37bd Reland "[clang-repl] Re-implement clang-interpreter as a test case."
Original commit message: "
    Original commit message: "
        Original commit message:"
          The current infrastructure in lib/Interpreter has a tool, clang-repl, very
          similar to clang-interpreter which also allows incremental compilation.

          This patch moves clang-interpreter as a test case and drops it as conditionally
          built example as we already have clang-repl in place.

          Differential revision: https://reviews.llvm.org/D107049
        "

        This patch also ignores ppc due to missing weak symbol for __gxx_personality_v0
        which may be a feature request for the jit infrastructure. Also, adds a missing
        build system dependency to the orc jit.
    "

    Additionally, this patch defines a custom exception type and thus avoids the
    requirement to include header <exception>, making it easier to deploy across
    systems without standard location of the c++ headers.
  "

  This patch also works around PR49692 and finds a way to use llvm::consumeError
  in rtti mode.

Differential revision: https://reviews.llvm.org/D107049
2021-10-08 06:04:39 +00:00
Luke Drummond 6283d468e2 Workaround build error for mingw-g++
mingw-g++ does not correctly support the full `std::errc` namespace as
worded in the standard[1]. As such, we cannot reliably use all names
therein. This patch changes the use of
`std::errc::state_not_recoverable`, to use portable error codes from the
`llvm::errc` equivalent.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71444

Reviewed by v.g.vassilev
Differential Revision: https://reviews.llvm.org/D111315
2021-10-07 18:34:16 +01:00
Vassil Vassilev f4f9ad0f5d Reland "[clang-repl] Allow loading of plugins in clang-repl."
Differential revision: https://reviews.llvm.org/D110484
2021-10-05 13:04:01 +00:00
Vassil Vassilev 3e9d04f7e4 Revert "[clang-repl] Allow loading of plugins in clang-repl."
This reverts commit 81fb640f83 due to bot failures:
https://lab.llvm.org/buildbot#builders/57/builds/10807
2021-10-05 06:10:38 +00:00
Vassil Vassilev 81fb640f83 [clang-repl] Allow loading of plugins in clang-repl.
Differential revision: https://reviews.llvm.org/D110484
2021-10-05 05:20:30 +00:00
Vassil Vassilev 8859640461 Revert "Reland "[clang-repl] Re-implement clang-interpreter as a test case.""
This reverts commit 6fe2beba7d which fails on
clang-hexagon-elf
2021-09-03 13:18:09 +00:00
Vassil Vassilev 6fe2beba7d Reland "[clang-repl] Re-implement clang-interpreter as a test case."
Original commit message: "
    Original commit message:"
      The current infrastructure in lib/Interpreter has a tool, clang-repl, very
      similar to clang-interpreter which also allows incremental compilation.

      This patch moves clang-interpreter as a test case and drops it as conditionally
      built example as we already have clang-repl in place.

      Differential revision: https://reviews.llvm.org/D107049
    "

    This patch also ignores ppc due to missing weak symbol for __gxx_personality_v0
    which may be a feature request for the jit infrastructure. Also, adds a missing
    build system dependency to the orc jit.
"

Additionally, this patch defines a custom exception type and thus avoids the
requirement to include header <exception>, making it easier to deploy across
systems without standard location of the c++ headers.

Differential revision: https://reviews.llvm.org/D107049
2021-09-03 12:02:58 +00:00
Jan Svoboda 555a817d1d [clang] NFC: Extract DiagnosticOptions parsing
The way we parse `DiagnosticOptions` is a bit involved.

`DiagnosticOptions` are parsed as part of the cc1-parsing function `CompilerInvocation::CreateFromArgs` which takes `DiagnosticsEngine` as an argument to be able to report errors in command-line arguments. But to create `DiagnosticsEngine`, `DiagnosticOptions` are needed. This is solved by exposing the `ParseDiagnosticArgs` to clients and making its `DiagnosticsEngine` argument optional, essentially breaking the dependency cycle.

The `ParseDiagnosticArgs` function takes `llvm::opt::ArgList &`, which each client needs to create from the command-line (typically represented as `std::vector<const char *>`). Creating this data structure in this context is somewhat particular. This code pattern is copy-pasted in some places across the upstream code base and also in downstream repos. To make things a bit more uniform, this patch extracts the code into a new reusable function: `CreateAndPopulateDiagOpts`.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D108918
2021-09-02 14:37:14 +02:00
Nico Weber 9b6c8132d3 Revert "Reland "[clang-repl] Re-implement clang-interpreter as a test case.""
This reverts commit f0514a4d26.
Test fails on macOS: https://reviews.llvm.org/D107049#2976603
2021-09-01 08:35:33 -04:00
Vassil Vassilev f0514a4d26 Reland "[clang-repl] Re-implement clang-interpreter as a test case."
Original commit message:"
  The current infrastructure in lib/Interpreter has a tool, clang-repl, very
  similar to clang-interpreter which also allows incremental compilation.

  This patch moves clang-interpreter as a test case and drops it as conditionally
  built example as we already have clang-repl in place.

  Differential revision: https://reviews.llvm.org/D107049
"

This patch also ignores ppc due to missing weak symbol for __gxx_personality_v0
which may be a feature request for the jit infrastructure. Also, adds a missing
build system dependency to the orc jit.
2021-09-01 10:21:38 +00:00
Vassil Vassilev 04bbd189a9 Revert "[clang-repl] Re-implement clang-interpreter as a test case."
This reverts commit 319ce98011 because it fails
on various platforms.
2021-09-01 06:49:52 +00:00
Vassil Vassilev 319ce98011 [clang-repl] Re-implement clang-interpreter as a test case.
The current infrastructure in lib/Interpreter has a tool, clang-repl, very
similar to clang-interpreter which also allows incremental compilation.

This patch moves clang-interpreter as a test case and drops it as conditionally
built example as we already have clang-repl in place.

Differential revision: https://reviews.llvm.org/D107049
2021-09-01 05:23:21 +00:00
Vassil Vassilev 11b47c103a 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 15:21:22 +00:00
Vassil Vassilev 5922f234c8 Revert "[clang-repl] Implement partial translation units and error recovery."
This reverts commit 6775fc6ffa.

It also reverts "[lldb] Fix compilation by adjusting to the new ASTContext signature."

This reverts commit 03a3f86071.

We see some failures on the lldb infrastructure, these changes might play a role
in it. Let's revert it now and see if the bots will become green.

Ref: https://reviews.llvm.org/D104918
2021-07-11 14:40:10 +00:00
Vassil Vassilev 6775fc6ffa [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-11 10:23:41 +00:00
Melanie Blower aaba37187f [clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D104729
2021-06-29 13:26:23 -04:00
Melanie Blower 1d85d0879a Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options"
This reverts commit 2dbe1c675f.
More buildbot failures
2021-06-28 15:47:21 -04:00
Melanie Blower 2dbe1c675f [clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D104729
2021-06-28 15:09:53 -04:00
Melanie Blower 8815ef823c Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options"
This reverts commit 2c02b0c3f4.
buildbot fails
2021-06-28 12:42:59 -04:00
Melanie Blower 2c02b0c3f4 [clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D104729
2021-06-28 12:26:53 -04:00
Stella Stamenova 734d688fbc [clang] Fix a race condition in the build of clangInterpreter
The library depends on Attributes.inc, so it has to depend on the intrinsics_gen target

Reviewed By: v.g.vassilev

Differential Revision: https://reviews.llvm.org/D104311
2021-06-17 10:03:33 -07:00
Vassil Vassilev 49f9532165 [clang-repl] Tell the LLJIT the exact target triple we use.
Some systems use a different data layout. For instance, s390x the layout of
machines with vector registers is different from the ones without. In such
cases, the JIT will automatically detect the vector registers and go out of
sync.

This patch tells the JIT what is the target triple of the generated code so that
both ends are in sync.

Discussion available in https://reviews.llvm.org/D96033. Thanks to @uweigand for
helping understand the issue.

Differential revision https://reviews.llvm.org/D102756
2021-05-21 08:16:42 +00:00
Vassil Vassilev 8dd5ef01ef [clang-repl] Better match the underlying architecture.
In cases where -fno-integrated-as is specified we should overwrite the
EmitAssembly action as well.

We also should rely on the target triple from the process at least until we
implement out-of-process execution.

This patch should improve clang-repl on AIX.

Discussion available at: https://reviews.llvm.org/D96033

Differential revision: https://reviews.llvm.org/D102688
2021-05-18 19:14:33 +00:00
Vassil Vassilev 3f4c518592 [clang-repl] Add exhaustive list of libInterpreter dependencies.
This patch should appease the bots building with -DBUILD_SHARED_LIBS=On,
resolving the regression introduced in 92f9852fc9.
2021-05-13 07:18:01 +00:00
Vassil Vassilev 92f9852fc9 [clang-repl] Recommit "Land initial infrastructure for incremental parsing"
Original commit message:

  In http://lists.llvm.org/pipermail/llvm-dev/2020-July/143257.html we have
  mentioned our plans to make some of the incremental compilation facilities
  available in llvm mainline.

  This patch proposes a minimal version of a repl, clang-repl, which enables
  interpreter-like interaction for C++. For instance:

  ./bin/clang-repl
  clang-repl> int i = 42;
  clang-repl> extern "C" int printf(const char*,...);
  clang-repl> auto r1 = printf("i=%d\n", i);
  i=42
  clang-repl> quit

  The patch allows very limited functionality, for example, it crashes on invalid
  C++. The design of the proposed patch follows closely the design of cling. The
  idea is to gather feedback and gradually evolve both clang-repl and cling to
  what the community agrees upon.

  The IncrementalParser class is responsible for driving the clang parser and
  codegen and allows the compiler infrastructure to process more than one input.
  Every input adds to the “ever-growing” translation unit. That model is enabled
  by an IncrementalAction which prevents teardown when HandleTranslationUnit.

  The IncrementalExecutor class hides some of the underlying implementation
  details of the concrete JIT infrastructure. It exposes the minimal set of
  functionality required by our incremental compiler/interpreter.

  The Transaction class keeps track of the AST and the LLVM IR for each
  incremental input. That tracking information will be later used to implement
  error recovery.

  The Interpreter class orchestrates the IncrementalParser and the
  IncrementalExecutor to model interpreter-like behavior. It provides the public
  API which can be used (in future) when using the interpreter library.

  Differential revision: https://reviews.llvm.org/D96033
2021-05-13 06:30:29 +00:00
Vassil Vassilev f6907152db Revert "[clang-repl] Land initial infrastructure for incremental parsing"
This reverts commit 44a4000181.

We are seeing build failures due to missing dependency to libSupport and
CMake Error at tools/clang/tools/clang-repl/cmake_install.cmake
file INSTALL cannot find
2021-05-13 04:44:19 +00:00
Vassil Vassilev 44a4000181 [clang-repl] Land initial infrastructure for incremental parsing
In http://lists.llvm.org/pipermail/llvm-dev/2020-July/143257.html we have
mentioned our plans to make some of the incremental compilation facilities
available in llvm mainline.

This patch proposes a minimal version of a repl, clang-repl, which enables
interpreter-like interaction for C++. For instance:

./bin/clang-repl
clang-repl> int i = 42;
clang-repl> extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=42
clang-repl> quit

The patch allows very limited functionality, for example, it crashes on invalid
C++. The design of the proposed patch follows closely the design of cling. The
idea is to gather feedback and gradually evolve both clang-repl and cling to
what the community agrees upon.

The IncrementalParser class is responsible for driving the clang parser and
codegen and allows the compiler infrastructure to process more than one input.
Every input adds to the “ever-growing” translation unit. That model is enabled
by an IncrementalAction which prevents teardown when HandleTranslationUnit.

The IncrementalExecutor class hides some of the underlying implementation
details of the concrete JIT infrastructure. It exposes the minimal set of
functionality required by our incremental compiler/interpreter.

The Transaction class keeps track of the AST and the LLVM IR for each
incremental input. That tracking information will be later used to implement
error recovery.

The Interpreter class orchestrates the IncrementalParser and the
IncrementalExecutor to model interpreter-like behavior. It provides the public
API which can be used (in future) when using the interpreter library.

Differential revision: https://reviews.llvm.org/D96033
2021-05-13 04:23:24 +00:00