History log of /llvm-project/clang/tools/clang-repl/ClangRepl.cpp (Results 26 – 45 of 45)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 6ad0788c 14-Jan-2023 Kazu Hirata <kazu@google.com>

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is p

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


# a1580d7b 14-Jan-2023 Kazu Hirata <kazu@google.com>

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Option

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


Revision tags: llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2
# 9caee577 31-Jul-2022 Jun Zhang <jun@junz.org>

[clang-repl] Fix incorrect return code

Without this patch, clang-repl incorrectly pass some tests when there's
error occured.

Signed-off-by: Jun Zhang <jun@junz.org>

Differential Revision: https:/

[clang-repl] Fix incorrect return code

Without this patch, clang-repl incorrectly pass some tests when there's
error occured.

Signed-off-by: Jun Zhang <jun@junz.org>

Differential Revision: https://reviews.llvm.org/D130422

show more ...


# a8f2e24e 30-Jul-2022 Sunho Kim <ksunhokim123@gmail.com>

[clang-repl] Disable building when LLVM_STATIC_LINK_CXX_STDLIB is ON.

We have seen random symbol not found "__cxa_throw" error in fuschia build bots and out-of-tree users. The understanding have bee

[clang-repl] Disable building when LLVM_STATIC_LINK_CXX_STDLIB is ON.

We have seen random symbol not found "__cxa_throw" error in fuschia build bots and out-of-tree users. The understanding have been that they are built without exception support, but it turned out that these platforms have LLVM_STATIC_LINK_CXX_STDLIB ON so that they link libstdc++ to llvm statically. The reason why this is problematic for clang-repl is that by default clang-repl tries to find symbols from symbol table of executable and dynamic libraries loaded by current process. It needs to load another libstdc++, but the platform that had LLVM_STATIC_LINK_CXX_STDLIB turned on is usally those with missing or obsolate shared libstdc++ in the first place -- trying to load it again would be destined to fail eventually with a risk to introuduce mixed libstdc++ versions.

A proper solution that doesn't take a workaround is statically link the same libstdc++ by clang-repl side, but this is not possible with old JIT linker runtimedyld. New just-in-time linker JITLink handles this relatively well, but it's not availalbe in majority of platforms. For now, this patch just disables the building of clang-repl when LLVM_STATIC_LINK_CXX_STDLIB is ON and removes the "__cxa_throw" check in exception unittest as well as reverting previous exception check flag patch.

Reviewed By: v.g.vassilev

Differential Revision: https://reviews.llvm.org/D130788

show more ...


Revision tags: llvmorg-15.0.0-rc1
# c619d4f8 28-Jul-2022 Sunho Kim <ksunhokim123@naver.com>

[clang-repl] Support destructors of global objects.

Supports destructors of global objects by properly calling jitdylib deinitialize which calls the global dtors of ir modules.

This supersedes http

[clang-repl] Support destructors of global objects.

Supports destructors of global objects by properly calling jitdylib deinitialize which calls the global dtors of ir modules.

This supersedes https://reviews.llvm.org/D127945. There was an issue when calling deinitialize on windows but it got fixed by https://reviews.llvm.org/D128037.

Reviewed By: v.g.vassilev

Differential Revision: https://reviews.llvm.org/D128589

show more ...


# 3cc3be8f 28-Jul-2022 Sunho Kim <ksunhokim123@gmail.com>

[clang-repl] Add host exception support check utility flag.

Add host exception support check utility flag. This is needed to not run tests that require exception support in few buildbots that lacks

[clang-repl] Add host exception support check utility flag.

Add host exception support check utility flag. This is needed to not run tests that require exception support in few buildbots that lacks related symbols for some reason.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D129242

show more ...


Revision tags: llvmorg-16-init
# 45b6c381 26-Jun-2022 Sunho Kim <ksunhokim123@gmail.com>

Revert "[clang-repl] Support destructors of global objects."

This reverts commit 9de8b05bfe0de2915d2443d06159396c5f9d389f.


Revision tags: llvmorg-14.0.6
# dea5a9cc 19-Jun-2022 Jun Zhang <jun@junz.org>

[clang-repl] Implement code undo.

In interactive C++ it is convenient to roll back to a previous state of the
compiler. For example:
clang-repl> int x = 42;
clang-repl> %undo
clang-repl> float x = 2

[clang-repl] Implement code undo.

In interactive C++ it is convenient to roll back to a previous state of the
compiler. For example:
clang-repl> int x = 42;
clang-repl> %undo
clang-repl> float x = 24 // not an error

To support this, the patch extends the functionality used to recover from
errors and adds functionality to recover the low-level execution infrastructure.

The current implementation is based on watermarks. It exploits the fact that
at each incremental input the underlying compiler infrastructure is in a valid
state. We can only go N incremental inputs back to a previous valid state. We do
not need and do not do any further dependency tracking.

This patch was co-developed with V. Vassilev, relies on the past work of Purva
Chaudhari in clang-repl and is inspired by the past work on the same feature
in the Cling interpreter.

Co-authored-by: Purva-Chaudhari <purva.chaudhari02@gmail.com>
Co-authored-by: Vassil Vassilev <v.g.vassilev@gmail.com>
Signed-off-by: Jun Zhang <jun@junz.org>

show more ...


# 9de8b05b 26-Jun-2022 Sunho Kim <ksunhokim123@gmail.com>

[clang-repl] Support destructors of global objects.

Supports destructors of global objects by properly calling jitdylib deinitialize which calls the global dtors of ir modules.

This supersedes http

[clang-repl] Support destructors of global objects.

Supports destructors of global objects by properly calling jitdylib deinitialize which calls the global dtors of ir modules.

This supersedes https://reviews.llvm.org/D127945. There was an issue when calling deinitialize on windows but it got fixed by https://reviews.llvm.org/D128037.

Reviewed By: v.g.vassilev

Differential Revision: https://reviews.llvm.org/D128589

show more ...


# 946c45a4 24-Jun-2022 Tapasweni Pathak <tapaswenipathak@gmail.com>

Implement soft reset of the diagnostics engine.

This patch implements soft reset and adds tests for soft reset success of the
diagnostics engine. This allows us to recover from errors in clang-repl

Implement soft reset of the diagnostics engine.

This patch implements soft reset and adds tests for soft reset success of the
diagnostics engine. This allows us to recover from errors in clang-repl without
resetting the pragma handlers' state.

Differential revision: https://reviews.llvm.org/D126183

show more ...


Revision tags: llvmorg-14.0.5
# d86a206f 05-Jun-2022 Fangrui Song <i@maskray.me>

Remove unneeded cl::ZeroOrMore for cl::opt/cl::list options


Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# f4f9ad0f 05-Oct-2021 Vassil Vassilev <v.g.vassilev@gmail.com>

Reland "[clang-repl] Allow loading of plugins in clang-repl."

Differential revision: https://reviews.llvm.org/D110484


# e463b697 05-Oct-2021 Simon Pilgrim <llvm-dev@redking.me.uk>

[Support] Change fatal_error_handler_t to take a const char* instead of std::string

https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html

Excessive use of the <

[Support] Change fatal_error_handler_t to take a const char* instead of std::string

https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html

Excessive use of the <string> header has a massive impact on compile time; its most commonly included via the ErrorHandling.h header, which has to be included in many key headers, impacting many source files that have no need for std::string.

As an initial step toward removing the <string> include from ErrorHandling.h, this patch proposes to update the fatal_error_handler_t handler to just take a raw const char* instead.

The next step will be to remove the report_fatal_error std::string variant, which will involve a lot of cleanup and better use of Twine/StringRef.

Differential Revision: https://reviews.llvm.org/D111049

show more ...


# 3e9d04f7 05-Oct-2021 Vassil Vassilev <v.g.vassilev@gmail.com>

Revert "[clang-repl] Allow loading of plugins in clang-repl."

This reverts commit 81fb640f83b6a5d099f9124739ab3049be79ea56 due to bot failures:
https://lab.llvm.org/buildbot#builders/57/builds/10807


# 81fb640f 25-Sep-2021 Vassil Vassilev <v.g.vassilev@gmail.com>

[clang-repl] Allow loading of plugins in clang-repl.

Differential revision: https://reviews.llvm.org/D110484


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init
# f01d45c3 10-Jul-2021 Vassil Vassilev <v.g.vassilev@gmail.com>

Reland "[clang-repl] Allow passing in code as positional arguments."

This reverts commit 3ec88ca60b24 which reverted e386871e1d21 due to a asan build
failure.

This patch removes the new lines in th

Reland "[clang-repl] Allow passing in code as positional arguments."

This reverts commit 3ec88ca60b24 which reverted e386871e1d21 due to a asan build
failure.

This patch removes the new lines in the test case which seem to introduce the
failure.

Differential revision: https://reviews.llvm.org/D104898

show more ...


# 3ec88ca6 02-Jul-2021 Mitch Phillips <31459023+hctim@users.noreply.github.com>

Revert "[clang-repl] Allow passing in code as positional arguments."

This reverts commit e386871e1d21cf206a1287356e88c5853563fc77.

Reason: Broke the ASan buildbots
(https://lab.llvm.org/buildbot/#/

Revert "[clang-repl] Allow passing in code as positional arguments."

This reverts commit e386871e1d21cf206a1287356e88c5853563fc77.

Reason: Broke the ASan buildbots
(https://lab.llvm.org/buildbot/#/builders/5/builds/9291). See comments
on https://reviews.llvm.org/D104898 for more information.

show more ...


# e386871e 01-Jul-2021 Vassil Vassilev <v.g.vassilev@gmail.com>

[clang-repl] Allow passing in code as positional arguments.

Now we can do things like: clang-repl "int i = 1;" "int j = 2;".

Differential revision: https://reviews.llvm.org/D104898


Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1
# 92f9852f 13-May-2021 Vassil Vassilev <v.g.vassilev@gmail.com>

[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 plan

[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

show more ...


# 44a40001 12-May-2021 Vassil Vassilev <v.g.vassilev@gmail.com>

[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 compila

[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

show more ...


12