#
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 ...
|