[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Lang Hames via Phabricator via cfe-commits]

lhames added a comment.

In D107049#3104558 , @dblaikie wrote:

> In D107049#3103984 , @lhames wrote:
>
>> In D107049#3101456 , @dblaikie 
>> wrote:
>>
>>> Yeah, seems we've had some precedent for this for a while, as @lhames says 
>>> (doing some archaeology I see one of the clang-interpreter tests added 
>>> here, for instance: 
>>> https://github.com/llvm/llvm-project/commit/1d487617f20ab9df65ab60d6cf9431ef288312ab
>>
>> Also all of the MJCIT and Orc tests in LLVM.
>
> I think @rnk was asking/drawing a distinction between execution tests in LLVM 
> (which is at least only testing LLVM code in LLVM) and execution tests in 
> Clang (which is both execution, and cross-project) - so I was just talking 
> about the Clang->LLVM->execution tests. Though I think in LLVM there'd also 
> be some opportunity to find some ways to isolate/test JIT infrastructure with 
> less execution (had sort of hoped in the early days of Orc that the layered 
> architecture would allow more isolated/unit testing to robustly test pieces 
> without execution for that testing).

Orc has plenty of isolated unit testing and regression testing too, it's just 
that the nature of the project (dynamic compilation, and with relatively few 
resources dedicated to it) makes end to end testing attractive for now too. 
Perhaps in the long term we could build out enough mocking infrastructure to be 
confident that the JIT works without running any JIT'd code, but we're a fair 
way off that.

I think testing of the clang-repl is probably in a similar place: In theory you 
could build infrastructure to test out all the interesting states that a REPL 
could put your AST into. In practice we don't have the resources to do that 
yet, and without execution tests we're left with essentially no testing of the 
feature.

Execution testing seems like the right compromise for now, as long as we can 
make sure that there's not too much noise from the testers. The lesson from the 
LLVM execution tests is that this is possible without an excessive amount of 
work.

> I think cross-project-tests (originally debuginfo-tests) has always had/been 
> a place for execution tests. Not all of them, and still value in having 
> lit-style non-execution cross-project tests where possible for more 
> robust/variation testing where possible, with fewer full 
> end-to-end-including-execution tests where possible (always going to be fuzzy 
> lines of what's worth the cost/benefit, etc - and we're all going to have 
> different points on that spectrum).

Yeah. Cross-project tests sounds like a great place to add more JIT tests, and 
maybe it's the correct home for clang-repl tests, but I think for now the right 
trade off is still to have execution tests and just restrict them to running on 
known-good configs.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D107049#3103984 , @lhames wrote:

> In D107049#3101456 , @dblaikie 
> wrote:
>
>> In D107049#3100630 , @rnk wrote:
>>
>>> So, to back up a bit, do I understand correctly that this change adds tests 
>>> to the check-clang test suite that JIT compiles C++ code for the host and 
>>> throws C++ exceptions? Can we reconsider that?
>>>
>>> We have a policy of not running execution tests in the clang test suite 
>>> because we know they always turn out to be unreliable, flaky, and highly 
>>> dependent on the environment rather than the code under test. Integration 
>>> tests are great, everyone needs them, but they should definitely not be 
>>> part of the default set of tests that developers run anywhere and 
>>> everywhere and expect to work out of the box, regardless of the 
>>> environment. +@dblaikie to confirm if I am off base here about our testing 
>>> strategy, and maybe Lang can advise us about past JIT testing strategies.
>>
>> Yeah, seems we've had some precedent for this for a while, as @lhames says 
>> (doing some archaeology I see one of the clang-interpreter tests added here, 
>> for instance: 
>> https://github.com/llvm/llvm-project/commit/1d487617f20ab9df65ab60d6cf9431ef288312ab
>
> Also all of the MJCIT and Orc tests in LLVM.

I think @rnk was asking/drawing a distinction between execution tests in LLVM 
(which is at least only testing LLVM code in LLVM) and execution tests in Clang 
(which is both execution, and cross-project) - so I was just talking about the 
Clang->LLVM->execution tests. Though I think in LLVM there'd also be some 
opportunity to find some ways to isolate/test JIT infrastructure with less 
execution (had sort of hoped in the early days of Orc that the layered 
architecture would allow more isolated/unit testing to robustly test pieces 
without execution for that testing).

>> I push back pretty hard on end-to-end tests in clang in most cases - one 
>> place that slips through either untested or with end to end tests is 
>> anything in MCOptions, etc, since they aren't in IR and are only observable 
>> through their effect on the resulting assembly. And JITs - I didn't actually 
>> know we had live JIT tests up in clang - and yeah, would rather we didn't - 
>> perhaps via a mode in such frontends that emits the IR at various points, 
>> but it'll be a pretty significant investment to make something fairly 
>> robust, I would imagine (sort of like lldb reproducers replays (which are 
>> being removed due to unmaintainability, by the sounds of it) but being able 
>> to stub out the actual execution) -  hmm, perhaps a remote execution mock 
>> would be feasible? That'd at least remove the execution part, make it 
>> portable to run on non-native environments - but wouldn't remove the 
>> end-to-end-ness, for that maybe you'd need a mock target that worked as 
>> though it ran IR natively, perhaps? Not sure.
>
> The LLVM MCJIT and Orc tests have been stable enough once we constrained the 
> environments that they run in. I don't see why this would be any less stable. 
> The features being exercised (essentially the object runtimes) are likely to 
> be more stable in practice than the environments being tested in the LLDB 
> tests.
>
>> Then maybe the more end-to-end-y tests could move out to cross-project-tests.
>
> Are you suggesting execution tests for cross-project-tests?

I think cross-project-tests (originally debuginfo-tests) has always had/been a 
place for execution tests. Not all of them, and still value in having lit-style 
non-execution cross-project tests where possible for more robust/variation 
testing where possible, with fewer full end-to-end-including-execution tests 
where possible (always going to be fuzzy lines of what's worth the 
cost/benefit, etc - and we're all going to have different points on that 
spectrum).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Lang Hames via Phabricator via cfe-commits]

lhames added a comment.

In D107049#3101456 , @dblaikie wrote:

> In D107049#3100630 , @rnk wrote:
>
>> So, to back up a bit, do I understand correctly that this change adds tests 
>> to the check-clang test suite that JIT compiles C++ code for the host and 
>> throws C++ exceptions? Can we reconsider that?
>>
>> We have a policy of not running execution tests in the clang test suite 
>> because we know they always turn out to be unreliable, flaky, and highly 
>> dependent on the environment rather than the code under test. Integration 
>> tests are great, everyone needs them, but they should definitely not be part 
>> of the default set of tests that developers run anywhere and everywhere and 
>> expect to work out of the box, regardless of the environment. +@dblaikie to 
>> confirm if I am off base here about our testing strategy, and maybe Lang can 
>> advise us about past JIT testing strategies.
>
> Yeah, seems we've had some precedent for this for a while, as @lhames says 
> (doing some archaeology I see one of the clang-interpreter tests added here, 
> for instance: 
> https://github.com/llvm/llvm-project/commit/1d487617f20ab9df65ab60d6cf9431ef288312ab

Also all of the MJCIT and Orc tests in LLVM.

> I push back pretty hard on end-to-end tests in clang in most cases - one 
> place that slips through either untested or with end to end tests is anything 
> in MCOptions, etc, since they aren't in IR and are only observable through 
> their effect on the resulting assembly. And JITs - I didn't actually know we 
> had live JIT tests up in clang - and yeah, would rather we didn't - perhaps 
> via a mode in such frontends that emits the IR at various points, but it'll 
> be a pretty significant investment to make something fairly robust, I would 
> imagine (sort of like lldb reproducers replays (which are being removed due 
> to unmaintainability, by the sounds of it) but being able to stub out the 
> actual execution) -  hmm, perhaps a remote execution mock would be feasible? 
> That'd at least remove the execution part, make it portable to run on 
> non-native environments - but wouldn't remove the end-to-end-ness, for that 
> maybe you'd need a mock target that worked as though it ran IR natively, 
> perhaps? Not sure.

The LLVM MCJIT and Orc tests have been stable enough once we constrained the 
environments that they run in. I don't see why this would be any less stable. 
The features being exercised (essentially the object runtimes) are likely to be 
more stable in practice than the environments being tested in the LLDB tests.

> Then maybe the more end-to-end-y tests could move out to cross-project-tests.

Are you suggesting execution tests for cross-project-tests?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D107049#3100939 , @lhames wrote:

> In D107049#3096727 , @uabelho wrote:
>
>> Hi,
>>
>> We're seeing a problem with this patch in our downstream (not public) 
>> buildbots. With an asan-built compiler we see the following:
>>
>>   ...
>>   10:08:55 [ RUN  ] InterpreterTest.CatchException
>>   10:08:55 libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
>>   10:08:55 libc++abi: terminating with uncaught exception of type 
>> custom_exception
>>   ...
>
> I suspect that this is a Linux distro that's using libunwind as the unwinder, 
> at least for this test. Linux distros typically use libgcc_s for unwinding. 
> The two libraries have different behavior for their `__register_frame` 
> functions: libunwind's function expects to be passed a single FDE, libgcc_s's 
> expects to be passed an entire .eh_frame section. We try to guess the 
> unwinder in the JIT and use the appropriate argument (see [1][2]), but when 
> we get it wrong this is often the result: we try to pass an .eh-frame section 
> to libunwind's `__register_frame` and it errors out on a CIE at the start of 
> the section.
>
> @uabelho -- In your setup I'm seeing:
>
>   -- Looking for __unw_add_dynamic_fde
>   -- Looking for __unw_add_dynamic_fde - not found
>
> So the question is, how are we failing to find `__unw_add_dynamic_fde` during 
> config, only to crash in it during the test? Is use of libunwind on your 
> platform expected?

Thanks for your reply. Unfortunately I'm not really sure how it's configured or 
what is expected. I'll try to involve someone who knows.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D107049#3100630 , @rnk wrote:

> So, to back up a bit, do I understand correctly that this change adds tests 
> to the check-clang test suite that JIT compiles C++ code for the host and 
> throws C++ exceptions? Can we reconsider that?
>
> We have a policy of not running execution tests in the clang test suite 
> because we know they always turn out to be unreliable, flaky, and highly 
> dependent on the environment rather than the code under test. Integration 
> tests are great, everyone needs them, but they should definitely not be part 
> of the default set of tests that developers run anywhere and everywhere and 
> expect to work out of the box, regardless of the environment. +@dblaikie to 
> confirm if I am off base here about our testing strategy, and maybe Lang can 
> advise us about past JIT testing strategies.

Yeah, seems we've had some precedent for this for a while, as @lhames says 
(doing some archaeology I see one of the clang-interpreter tests added here, 
for instance: 
https://github.com/llvm/llvm-project/commit/1d487617f20ab9df65ab60d6cf9431ef288312ab

I push back pretty hard on end-to-end tests in clang in most cases - one place 
that slips through either untested or with end to end tests is anything in 
MCOptions, etc, since they aren't in IR and are only observable through their 
effect on the resulting assembly. And JITs - I didn't actually know we had live 
JIT tests up in clang - and yeah, would rather we didn't - perhaps via a mode 
in such frontends that emits the IR at various points, but it'll be a pretty 
significant investment to make something fairly robust, I would imagine (sort 
of like lldb reproducers replays (which are being removed due to 
unmaintainability, by the sounds of it) but being able to stub out the actual 
execution) - hmm, perhaps a remote execution mock would be feasible? That'd at 
least remove the execution part, make it portable to run on non-native 
environments - but wouldn't remove the end-to-end-ness, for that maybe you'd 
need a mock target that worked as though it ran IR natively, perhaps? Not sure.

Then maybe the more end-to-end-y tests could move out to cross-project-tests.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Lang Hames via Phabricator via cfe-commits]

lhames added a comment.

In D107049#3096727 , @uabelho wrote:

> Hi,
>
> We're seeing a problem with this patch in our downstream (not public) 
> buildbots. With an asan-built compiler we see the following:
>
>   ...
>   10:08:55 [ RUN  ] InterpreterTest.CatchException
>   10:08:55 libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
>   10:08:55 libc++abi: terminating with uncaught exception of type 
> custom_exception
>   ...

I suspect that this is a Linux distro that's using libunwind as the unwinder, 
at least for this test. Linux distros typically use libgcc_s for unwinding. The 
two libraries have different behavior for their `__register_frame` functions: 
libunwind's function expects to be passed a single FDE, libgcc_s's expects to 
be passed an entire .eh_frame section. We try to guess the unwinder in the JIT 
and use the appropriate argument (see [1][2]), but when we get it wrong this is 
often the result: we try to pass an .eh-frame section to libunwind's 
`__register_frame` and it errors out on a CIE at the start of the section.

@uabelho -- In your setup I'm seeing:

  -- Looking for __unw_add_dynamic_fde
  -- Looking for __unw_add_dynamic_fde - not found

So the question is, how are we failing to find `__unw_add_dynamic_fde` during 
config, only to crash in it during the test? Is use of libunwind on your 
platform expected?

side note: Peter Housel recently posted https://reviews.llvm.org/D111863 to add 
a new registration API with consistent behavior. Hopefully in the future we can 
rely on dynamic detection of this to eliminate the issue for users of future 
libunwinds.

In D107049#3100630 , @rnk wrote:

> So, to back up a bit, do I understand correctly that this change adds tests 
> to the check-clang test suite that JIT compiles C++ code for the host and 
> throws C++ exceptions? Can we reconsider that?
>
> We have a policy of not running execution tests in the clang test suite 
> because we know they always turn out to be unreliable, flaky, and highly 
> dependent on the environment rather than the code under test. Integration 
> tests are great, everyone needs them, but they should definitely not be part 
> of the default set of tests that developers run anywhere and everywhere and 
> expect to work out of the box, regardless of the environment. +@dblaikie to 
> confirm if I am off base here about our testing strategy, and maybe Lang can 
> advise us about past JIT testing strategies.

The JIT has always used execution tests. It's difficult to test the JIT 
properly without them, since it doesn't have persistent output.

In practice the trick has always been to tighten the criteria for where these 
can run until things stabilize. We're seeing more failures on the test cases 
that Vassil is writing because he's pushing the boundaries of ORC's feature 
set, but I think the solution should still be the same: fix the JIT when we 
find bugs there, and restrict the tests to environments where they're expected 
to pass.

[1] 
https://github.com/llvm/llvm-project/commit/957334382cd12ec07b46c0ddfdcc220731f6d80f
[2] https://llvm.org/PR44074


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a subscriber: dblaikie.
rnk added a comment.

So, to back up a bit, do I understand correctly that this change adds tests to 
the check-clang test suite that JIT compiles C++ code for the host and throws 
C++ exceptions? Can we reconsider that?

We have a policy of not running execution tests in the clang test suite because 
we know they always turn out to be unreliable, flaky, and highly dependent on 
the environment rather than the code under test. Integration tests are great, 
everyone needs them, but they should definitely not be part of the default set 
of tests that developers run anywhere and everywhere and expect to work out of 
the box, regardless of the environment. +@dblaikie to confirm if I am off base 
here about our testing strategy, and maybe Lang can advise us about past JIT 
testing strategies.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D107049#3099941 , @v.g.vassilev 
wrote:

> Can you also paste the configure output of cmake?

Attached in file.txt F20006228: file.txt 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

In D107049#3099816 , @uabelho wrote:

> In D107049#3096807 , @v.g.vassilev 
> wrote:
>
>> Can you share your cmake config line, the target triple and architecture?
>
> CC='/mycompiler/compiler-clang/bin/clang -march=corei7' 
> CXX='/mycompiler/compiler-clang/bin/clang++ -march=corei7' 
> LDFLAGS='-L/mycompiler/compiler-clang/lib64 
> -Wl,--disable-new-dtags,-R/mycompiler/compiler-clang/lib/x86_64-unknown-linux-gnu/c++:/mycompiler/compiler-clang/lib64:/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1/lib64
>  -ldl' cmake /repo/llvm --debug-trycompile -G Ninja 
> -DCMAKE_MAKE_PROGRAM=ninja -DCMAKE_BUILD_TYPE=Release 
> -DCMAKE_C_FLAGS='-Wno-error=unused-command-line-argument' 
> -DCMAKE_CXX_FLAGS='-stdlib=libc++' -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
> -DCMAKE_INSTALL_PREFIX=/compiler-clang -DLLVM_APPEND_VC_REV=OFF 
> -DLLVM_CCACHE_DIR=/repo/.ccache -DLLVM_CCACHE_BUILD=ON 
> -DLLVM_CCACHE_PROGRAM=/app/vbuild/RHEL7-x86_64/ccache/3.2.2/bin/ccache 
> -DLLVM_CCACHE_NOHASHDIR=ON -DLLVM_CCACHE_BASEDIR=/repo 
> -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_WERROR=ON 
> -DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld' 
> -DLLVM_ENABLE_Z3_SOLVER=ON 
> -DLLVM_Z3_INSTALL_DIR=/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1 
> -DLLVM_LIT_ARGS='-sv --threads 14' -DLLVM_ENABLE_PLUGINS=OFF 
> -DLLVM_USE_SANITIZER='Address' -DLLVM_ENABLE_LIBPFM=OFF 
> -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_TERMINFO=OFF 
> -DLLVM_STATIC_LINK_CXX_STDLIB=ON -DCLANG_ENABLE_ARCMT=OFF 
> -DCLANG_TOOLING_BUILD_AST_INTROSPECTION=OFF -DCLANG_ROUND_TRIP_CC1_ARGS=OFF

Can you also paste the configure output of cmake?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

If we run without z3 it still fails, but in another way:

  [ RUN  ] InterpreterTest.CatchException
  JIT session error: Symbols not found: [ __gxx_personality_v0, 
_ZSt9terminatev, _ZTVN10__cxxabiv117__class_type_infoE, 
__cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, 
__cxa_free_exception ]
  Failure value returned from cantFail wrapped call
  Failed to materialize symbols: { (main, { __clang_call_terminate, 
_ZN16custom_exceptionC2EPKc, throw_exception, _ZTS16custom_exception, 
_ZTI16custom_exception }) }
  UNREACHABLE executed at 
/repo/uabelho/master-github/llvm/include/llvm/Support/Error.h:788!
   #0 0x0051c0fb backtrace 
/repo/uabelho/flacc_6.144/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:4205:13
   #1 0x0186f144 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:565:13
   #2 0x01867cf8 llvm::sys::RunSignalHandlers() 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../lib/Support/Signals.cpp:0:5
   #3 0x0186ff78 SignalHandler(int) 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:0:3
   #4 0x7fdcac5bd630 __restore_rt sigaction.c:0:0
   #5 0x7fdcab8e0387 raise (/lib64/libc.so.6+0x36387)
   #6 0x7fdcab8e1a78 abort (/lib64/libc.so.6+0x37a78)
   #7 0x01708875 operator<< 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../include/llvm/Support/raw_ostream.h:221:7
   #8 0x01708875 operator<< 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../include/llvm/Support/raw_ostream.h:231:18
   #9 0x01708875 llvm::llvm_unreachable_internal(char const*, char 
const*, unsigned int) 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../lib/Support/ErrorHandling.cpp:204:19
  #10 0x00590b65 unsigned long llvm::cantFail(llvm::Expected, char const*) 
/repo/uabelho/master-github/llvm/include/llvm/Support/Error.h:777:12
  #11 0x0058e5b8 (anonymous 
namespace)::InterpreterTest_CatchException_Test::TestBody() 
/repo/uabelho/master-github/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:0:0
  #12 0x018abce8 os_stack_trace_getter 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:5635:7
  #13 0x018abce8 testing::Test::Run() 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:2515:9
  #14 0x018aeb03 testing::TestInfo::Run() 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:0:11
  #15 0x018aff71 testing::TestSuite::Run() 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:0:28
  #16 0x018dfaa9 testing::internal::UnitTestImpl::RunAllTests() 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:0:44
  #17 0x018ddc8e testing::UnitTest::Run() 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/googletest/src/gtest.cc:4925:10
  #18 0x0188fbce main 
/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/../utils/unittest/UnitTestMain/TestMain.cpp:50:3
  #19 0x7fdcab8cc555 __libc_start_main (/lib64/libc.so.6+0x22555)
  #20 0x004e59c7 _start 
(/repo/uabelho/master-github/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0x4e59c7)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D107049#3096807 , @v.g.vassilev 
wrote:

> Can you share your cmake config line, the target triple and architecture?

CC='/mycompiler/compiler-clang/bin/clang -march=corei7' 
CXX='/mycompiler/compiler-clang/bin/clang++ -march=corei7' 
LDFLAGS='-L/mycompiler/compiler-clang/lib64 
-Wl,--disable-new-dtags,-R/mycompiler/compiler-clang/lib/x86_64-unknown-linux-gnu/c++:/mycompiler/compiler-clang/lib64:/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1/lib64
 -ldl' cmake /repo/llvm --debug-trycompile -G Ninja -DCMAKE_MAKE_PROGRAM=ninja 
-DCMAKE_BUILD_TYPE=Release 
-DCMAKE_C_FLAGS='-Wno-error=unused-command-line-argument' 
-DCMAKE_CXX_FLAGS='-stdlib=libc++' -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
-DCMAKE_INSTALL_PREFIX=/compiler-clang -DLLVM_APPEND_VC_REV=OFF 
-DLLVM_CCACHE_DIR=/repo/.ccache -DLLVM_CCACHE_BUILD=ON 
-DLLVM_CCACHE_PROGRAM=/app/vbuild/RHEL7-x86_64/ccache/3.2.2/bin/ccache 
-DLLVM_CCACHE_NOHASHDIR=ON -DLLVM_CCACHE_BASEDIR=/repo 
-DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_WERROR=ON 
-DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld' -DLLVM_ENABLE_Z3_SOLVER=ON 
-DLLVM_Z3_INSTALL_DIR=/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1 
-DLLVM_LIT_ARGS='-sv --threads 14' -DLLVM_ENABLE_PLUGINS=OFF 
-DLLVM_USE_SANITIZER='Address' -DLLVM_ENABLE_LIBPFM=OFF 
-DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_TERMINFO=OFF 
-DLLVM_STATIC_LINK_CXX_STDLIB=ON -DCLANG_ENABLE_ARCMT=OFF 
-DCLANG_TOOLING_BUILD_AST_INTROSPECTION=OFF -DCLANG_ROUND_TRIP_CC1_ARGS=OFF


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev marked an inline comment as done.
v.g.vassilev added a comment.

In D107049#3096727 , @uabelho wrote:

> Hi,
>
> We're seeing a problem with this patch in our downstream (not public) 
> buildbots. With an asan-built compiler we see the following:
>
>   10:08:55 FAIL: Clang-Unit :: 
> Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException
>  (25832 of 79960)
>   10:08:55  TEST 'Clang-Unit :: 
> Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException'
>  FAILED 
>   10:08:55 Script:
>   10:08:55 --
>   10:08:55 
> /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests
>  --gtest_filter=InterpreterTest.CatchException
>   10:08:55 --
>   10:08:55 Note: Google Test filter = InterpreterTest.CatchException
>   10:08:55 [==] Running 1 test from 1 test suite.
>   10:08:55 [--] Global test environment set-up.
>   10:08:55 [--] 1 test from InterpreterTest
>   10:08:55 [ RUN  ] InterpreterTest.CatchException
>   10:08:55 libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
>   10:08:55 libc++abi: terminating with uncaught exception of type 
> custom_exception
>   10:08:55  #0 0x0052072b backtrace 
> /repo/uabelho/flacc_6.144/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:4205:13
>   10:08:55  #1 0x01873774 
> llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
> /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:565:13
>   10:08:55  #2 0x0186c328 llvm::sys::RunSignalHandlers() 
> /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/../lib/Support/Signals.cpp:0:5
>   10:08:55  #3 0x018745a8 SignalHandler(int) 
> /repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:0:3
>   10:08:55  #4 0x7f61246da630 __restore_rt sigaction.c:0:0
>   10:08:55  #5 0x7f6122025387 raise (/lib64/libc.so.6+0x36387)
>   10:08:55  #6 0x7f6122026a78 abort (/lib64/libc.so.6+0x37a78)
>   10:08:55  #7 0x0cbdedd6 
> (/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0xcbdedd6)
>   10:08:55  #8 0x0cbe4407 
> (/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0xcbe4407)
>   10:08:55  #9 0x0cbdecb3 std::__terminate(void (*)()) crtstuff.c:0:0
>   10:08:55 #10 0x0cbdca26 
> (/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0xcbdca26)
>   10:08:55 #11 0x0cbdc9c0 
> __cxxabiv1::exception_cleanup_func(_Unwind_Reason_Code, _Unwind_Exception*) 
> cxa_exception.cpp:0:0
>   10:08:55 #12 0x7f611ea00171 
>   10:08:55 
>   10:08:55 
>   10:08:55 Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
>   10:25:10 
>   10:25:10 1 warning(s) in tests
>   10:25:10 
>   10:25:10 Failed Tests (1):
>   10:25:10   Clang-Unit :: 
> Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException
>   10:25:10 
>
> Does an asan-build run clean for everyone else?

Can you share your cmake config line, the target triple and architecture?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

We're seeing a problem with this patch in our downstream (not public) 
buildbots. With an asan-built compiler we see the following:

  10:08:55 FAIL: Clang-Unit :: 
Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException
 (25832 of 79960)
  10:08:55  TEST 'Clang-Unit :: 
Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException'
 FAILED 
  10:08:55 Script:
  10:08:55 --
  10:08:55 
/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests
 --gtest_filter=InterpreterTest.CatchException
  10:08:55 --
  10:08:55 Note: Google Test filter = InterpreterTest.CatchException
  10:08:55 [==] Running 1 test from 1 test suite.
  10:08:55 [--] Global test environment set-up.
  10:08:55 [--] 1 test from InterpreterTest
  10:08:55 [ RUN  ] InterpreterTest.CatchException
  10:08:55 libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE
  10:08:55 libc++abi: terminating with uncaught exception of type 
custom_exception
  10:08:55  #0 0x0052072b backtrace 
/repo/uabelho/flacc_6.144/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:4205:13
  10:08:55  #1 0x01873774 
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:565:13
  10:08:55  #2 0x0186c328 llvm::sys::RunSignalHandlers() 
/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/../lib/Support/Signals.cpp:0:5
  10:08:55  #3 0x018745a8 SignalHandler(int) 
/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/../lib/Support/Unix/Signals.inc:0:3
  10:08:55  #4 0x7f61246da630 __restore_rt sigaction.c:0:0
  10:08:55  #5 0x7f6122025387 raise (/lib64/libc.so.6+0x36387)
  10:08:55  #6 0x7f6122026a78 abort (/lib64/libc.so.6+0x37a78)
  10:08:55  #7 0x0cbdedd6 
(/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0xcbdedd6)
  10:08:55  #8 0x0cbe4407 
(/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0xcbe4407)
  10:08:55  #9 0x0cbdecb3 std::__terminate(void (*)()) crtstuff.c:0:0
  10:08:55 #10 0x0cbdca26 
(/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-sanitize-asan/llvm/build-all-bbisdk-asan/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests+0xcbdca26)
  10:08:55 #11 0x0cbdc9c0 
__cxxabiv1::exception_cleanup_func(_Unwind_Reason_Code, _Unwind_Exception*) 
cxa_exception.cpp:0:0
  10:08:55 #12 0x7f611ea00171 
  10:08:55 
  10:08:55 
  10:08:55 Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
  10:25:10 
  10:25:10 1 warning(s) in tests
  10:25:10 
  10:25:10 Failed Tests (1):
  10:25:10   Clang-Unit :: 
Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException
  10:25:10 

Does an asan-build run clean for everyone else?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev marked an inline comment as done.
v.g.vassilev added inline comments.



Comment at: clang/unittests/Interpreter/CMakeLists.txt:5
+  OrcJIT
+  Support
   )

thakis wrote:
> v.g.vassilev wrote:
> > v.g.vassilev wrote:
> > > thakis wrote:
> > > > Why are these additions needed here again? This change doesn't add any 
> > > > code to ClangReplInterpreterTests as far as I can tell. Are these 
> > > > remnants from before the exception tests were in a different binary?
> > > Thanks for noticing that. The story was that 
> > > `clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt` required 
> > > `${LLVM_TARGETS_TO_BUILD} Core OrcJIT Support` as a dependency -- I was 
> > > not sure why but I added the same here. I am testing now if I can get rid 
> > > of both. I do not understand why we will need different set of 
> > > dependencies for these tests as they should be using more or less the 
> > > same set of functionality...
> > I dropped these dependencies as you mentioned -- thanks again.
> Looks like they're back in the reland. Mind dropping them again?
Yeah, thanks for keeping an eye on this. Not sure what I did wrong there.. Too 
many reverts I guess...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: clang/unittests/Interpreter/CMakeLists.txt:5
+  OrcJIT
+  Support
   )

v.g.vassilev wrote:
> v.g.vassilev wrote:
> > thakis wrote:
> > > Why are these additions needed here again? This change doesn't add any 
> > > code to ClangReplInterpreterTests as far as I can tell. Are these 
> > > remnants from before the exception tests were in a different binary?
> > Thanks for noticing that. The story was that 
> > `clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt` required 
> > `${LLVM_TARGETS_TO_BUILD} Core OrcJIT Support` as a dependency -- I was not 
> > sure why but I added the same here. I am testing now if I can get rid of 
> > both. I do not understand why we will need different set of dependencies 
> > for these tests as they should be using more or less the same set of 
> > functionality...
> I dropped these dependencies as you mentioned -- thanks again.
Looks like they're back in the reland. Mind dropping them again?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added inline comments.



Comment at: clang/unittests/Interpreter/CMakeLists.txt:5
+  OrcJIT
+  Support
   )

v.g.vassilev wrote:
> thakis wrote:
> > Why are these additions needed here again? This change doesn't add any code 
> > to ClangReplInterpreterTests as far as I can tell. Are these remnants from 
> > before the exception tests were in a different binary?
> Thanks for noticing that. The story was that 
> `clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt` required 
> `${LLVM_TARGETS_TO_BUILD} Core OrcJIT Support` as a dependency -- I was not 
> sure why but I added the same here. I am testing now if I can get rid of 
> both. I do not understand why we will need different set of dependencies for 
> these tests as they should be using more or less the same set of 
> functionality...
I dropped these dependencies as you mentioned -- thanks again.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

In D107049#3052557 , @leonardchan 
wrote:

> Hi. I think our clang builders are failing from this after the reland 
> (https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8833962834812688769/overview):
>
>   Script:
>   --
>   
> /b/s/w/ir/x/w/staging/llvm_build/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests
>  --gtest_filter=InterpreterTest.CatchException
>   --
>   Note: Google Test filter = InterpreterTest.CatchException
>   [==] Running 1 test from 1 test suite.
>   [--] Global test environment set-up.
>   [--] 1 test from InterpreterTest
>   [ RUN  ] InterpreterTest.CatchException
>   JIT session error: Symbols not found: [ _Unwind_Resume, _ZSt9terminatev, 
> _ZTVN10__cxxabiv117__class_type_infoE, __cxa_allocate_exception, 
> __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_throw, 
> __gxx_personality_v0 ]
>   Failure value returned from cantFail wrapped call
>   Failed to materialize symbols: { (main, { __clang_call_terminate, 
> _ZTI16custom_exception, _ZN16custom_exceptionC2EPKc, _ZTS16custom_exception, 
> throw_exception }) }
>   UNREACHABLE executed at llvm/include/llvm/Support/Error.h:778!
>
> Would you be able to send out a fix or revert?

Thanks for reverting. I will look into this failure.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Leonard Chan via Phabricator via cfe-commits]

leonardchan added a comment.

Hi. I think our clang builders are failing from this after the reland 
(https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8833962834812688769/overview):

  Script:
  --
  
/b/s/w/ir/x/w/staging/llvm_build/tools/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests
 --gtest_filter=InterpreterTest.CatchException
  --
  Note: Google Test filter = InterpreterTest.CatchException
  [==] Running 1 test from 1 test suite.
  [--] Global test environment set-up.
  [--] 1 test from InterpreterTest
  [ RUN  ] InterpreterTest.CatchException
  JIT session error: Symbols not found: [ _Unwind_Resume, _ZSt9terminatev, 
_ZTVN10__cxxabiv117__class_type_infoE, __cxa_allocate_exception, 
__cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_throw, 
__gxx_personality_v0 ]
  Failure value returned from cantFail wrapped call
  Failed to materialize symbols: { (main, { __clang_call_terminate, 
_ZTI16custom_exception, _ZN16custom_exceptionC2EPKc, _ZTS16custom_exception, 
throw_exception }) }
  UNREACHABLE executed at llvm/include/llvm/Support/Error.h:778!

Would you be able to send out a fix or revert?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added inline comments.



Comment at: clang/unittests/Interpreter/CMakeLists.txt:5
+  OrcJIT
+  Support
   )

thakis wrote:
> Why are these additions needed here again? This change doesn't add any code 
> to ClangReplInterpreterTests as far as I can tell. Are these remnants from 
> before the exception tests were in a different binary?
Thanks for noticing that. The story was that 
`clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt` required 
`${LLVM_TARGETS_TO_BUILD} Core OrcJIT Support` as a dependency -- I was not 
sure why but I added the same here. I am testing now if I can get rid of both. 
I do not understand why we will need different set of dependencies for these 
tests as they should be using more or less the same set of functionality...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: clang/unittests/Interpreter/CMakeLists.txt:5
+  OrcJIT
+  Support
   )

Why are these additions needed here again? This change doesn't add any code to 
ClangReplInterpreterTests as far as I can tell. Are these remnants from before 
the exception tests were in a different binary?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added inline comments.



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:102
+  } catch (...) {
+printf("Unknown exception\n");
+  }

karies wrote:
> How is that provoking a test failure? What about `exit(1)` or whatever works 
> for gtest?
we use EXPECT_ANY_THROW and expect output on the stdout. I guess that line is 
not reachable.



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:104
+  }
+  ThrowerAnError("From JIT");
+  return 0;

karies wrote:
> To me, the wording difference between "In JIT" and "From JIT" doesn't signal 
> anything. Maybe "the first could be "To be caught in JIT" and the second "To 
> be caught in binary"?
The intent was to show that we can move the clang-interpreter example with 
relatively small amount of changes to the libInterpreter interfaces. we have 
changed that goal significantly and maybe we should also change the strings, 
too.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 377307.
v.g.vassilev marked 5 inline comments as done.
v.g.vassilev added a comment.

address comments


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

Files:
  clang/examples/CMakeLists.txt
  clang/examples/clang-interpreter/CMakeLists.txt
  clang/examples/clang-interpreter/README.txt
  clang/examples/clang-interpreter/Test.cxx
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Misc/interpreter.c
  clang/test/lit.cfg.py
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -17,8 +17,6 @@
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
-#include "llvm/ADT/ArrayRef.h"
-
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- /dev/null
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -0,0 +1,131 @@
+//===- unittests/Interpreter/InterpreterExceptionTest.cpp -===//
+//
+// 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
+//
+//===--===//
+//
+// Unit tests for Clang's Interpreter library.
+//
+//===--===//
+
+#include "clang/Interpreter/Interpreter.h"
+
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclGroup.h"
+#include "clang/Basic/TargetInfo.h"
+#include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ExecutionEngine/Orc/LLJIT.h"
+#include "llvm/Support/ManagedStatic.h"
+#include "llvm/Support/TargetSelect.h"
+
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+using Args = std::vector;
+static std::unique_ptr
+createInterpreter(const Args &ExtraArgs = {},
+  DiagnosticConsumer *Client = nullptr) {
+  Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
+  ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
+  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  if (Client)
+CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
+  return cantFail(clang::Interpreter::create(std::move(CI)));
+}
+
+TEST(InterpreterTest, CatchException) {
+  llvm::InitializeNativeTarget();
+  llvm::InitializeNativeTargetAsmPrinter();
+
+  {
+auto J = llvm::orc::LLJITBuilder().create();
+if (!J) {
+  // The platform does not support JITs.
+  // We can't use llvm::consumeError as it needs typeinfo for ErrorInfoBase.
+  auto E = J.takeError();
+  (void)E;
+  return;
+}
+  }
+
+#define Stringify(s) Stringifyx(s)
+#define Stringifyx(s) #s
+
+  // We define a custom exception to avoid #include-ing the  header
+  // which would require this test to know about the libstdc++ location.
+  // its own header file.
+#define CUSTOM_EXCEPTION   \
+  struct custom_exception {\
+custom_exception(const char *Msg) : Message(Msg) {}\
+const char *Message;   \
+  };
+
+  CUSTOM_EXCEPTION;
+
+  std::string ExceptionCode = Stringify(CUSTOM_EXCEPTION);
+  ExceptionCode +=
+  R"(
+extern "C" int printf(const char*, ...);
+static void ThrowerAnError(const char* Name) {
+  throw custom_exception(Name);
+}
+
+extern "C" int throw_exception() {
+  try {
+ThrowerAnError("To be caught in JIT");
+  } catch (const custom_exception& E) {
+printf("Caught: '%s'\n", E.Message);
+  } catch (...) {
+printf("Unknown exception\n");
+  }
+  ThrowerAnError("To be caught in binary");
+  return 0;
+}
+)";
+  std::unique_ptr Interp = createInterpreter();
+  // FIXME: Re-enable the excluded target triples.
+  const clang::CompilerInstance *CI = Interp->getCompilerInstance();
+  const llvm::Triple &Triple = CI->getASTContext().getTargetInfo().getTri

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 377303.
v.g.vassilev added a comment.

Upload the newest version of this patch. It has several improvements that came 
from various bot failures. We just need to outline the `llvm::consumeError` to 
be able to call it from exceptions land and fix the last known failure on 
hexagon.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

Files:
  clang/docs/ClangFormattedStatus.rst
  clang/examples/CMakeLists.txt
  clang/examples/clang-interpreter/CMakeLists.txt
  clang/examples/clang-interpreter/README.txt
  clang/examples/clang-interpreter/Test.cxx
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Misc/interpreter.c
  clang/test/lit.cfg.py
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -17,8 +17,6 @@
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
-#include "llvm/ADT/ArrayRef.h"
-
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- /dev/null
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -0,0 +1,131 @@
+//===- unittests/Interpreter/InterpreterExceptionTest.cpp -===//
+//
+// 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
+//
+//===--===//
+//
+// Unit tests for Clang's Interpreter library.
+//
+//===--===//
+
+#include "clang/Interpreter/Interpreter.h"
+
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclGroup.h"
+#include "clang/Basic/TargetInfo.h"
+#include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ExecutionEngine/Orc/LLJIT.h"
+#include "llvm/Support/ManagedStatic.h"
+#include "llvm/Support/TargetSelect.h"
+
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+using Args = std::vector;
+static std::unique_ptr
+createInterpreter(const Args &ExtraArgs = {},
+  DiagnosticConsumer *Client = nullptr) {
+  Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
+  ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
+  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  if (Client)
+CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
+  return cantFail(clang::Interpreter::create(std::move(CI)));
+}
+
+TEST(InterpreterTest, CatchException) {
+  llvm::InitializeNativeTarget();
+  llvm::InitializeNativeTargetAsmPrinter();
+
+  {
+auto J = llvm::orc::LLJITBuilder().create();
+if (!J) {
+  // The platform does not support JITs.
+  // We can't use llvm::consumeError as it needs typeinfo for ErrorInfoBase.
+  auto E = J.takeError();
+  (void)E;
+  return;
+}
+  }
+
+#define Stringify(s) Stringifyx(s)
+#define Stringifyx(s) #s
+
+  // We define a custom exception to avoid #include-ing the  header
+  // which would require this test to know about the libstdc++ location.
+  // its own header file.
+#define CUSTOM_EXCEPTION   \
+  struct custom_exception {\
+custom_exception(const char *Msg) : Message(Msg) {}\
+const char *Message;   \
+  };
+
+  CUSTOM_EXCEPTION;
+
+  std::string ExceptionCode = Stringify(CUSTOM_EXCEPTION);
+  ExceptionCode +=
+  R"(
+extern "C" int printf(const char*, ...);
+static void ThrowerAnError(const char* Name) {
+  throw custom_exception(Name);
+}
+
+extern "C" int throw_exception() {
+  try {
+ThrowerAnError("In JIT");
+  } catch (const custom_exception& E) {
+printf("Caught: '%s'\n", E.Message);
+  } catch (...) {
+printf("Unknown exception\n");
+  }
+  ThrowerAnError("From JIT");
+  return 0;
+}
+)";
+  std::unique_ptr Interp = createInterpreter();
+  //

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Axel Naumann via Phabricator via cfe-commits]

karies added inline comments.



Comment at: clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt:2
+# The interpreter can throw an exception from user input. The test binary needs
+# to be compiled with exception support to expect and catch the thrown
+# exception.

I don't understand the term "to expect" the thrown exception. Please ignore if 
that's a known term of art.



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:93
+static void ThrowerAnError(const char* Name) {
+  throw std::runtime_error(Name);
+}

Why not just `throw Name;` to avoid `#include `?



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:100
+  } catch (const std::exception& E) {
+printf("Caught: '%s'\n", E.what());
+  } catch (...) {

Consider fwd declaring `printf` to avoid inclusion of `stdio.h`.



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:102
+  } catch (...) {
+printf("Unknown exception\n");
+  }

How is that provoking a test failure? What about `exit(1)` or whatever works 
for gtest?



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:104
+  }
+  ThrowerAnError("From JIT");
+  return 0;

To me, the wording difference between "In JIT" and "From JIT" doesn't signal 
anything. Maybe "the first could be "To be caught in JIT" and the second "To be 
caught in binary"?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld added a comment.

In D107049#2984835 , @v.g.vassilev 
wrote:

> It looks like we hit https://bugs.llvm.org/show_bug.cgi?id=49692

I agree. Unfortunately, as described in the report, this is something that 
needs to be fixed on Apples side first.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added subscribers: karies, Hahnfeld.
v.g.vassilev added a comment.

In D107049#2982224 , @thakis wrote:

> Thanks for fixing! Intel macs are happy now.
>
> But the test is still failing on arm macs: 
> http://45.33.8.238/macm1/17292/step_7.txt
>
>   FAIL: Clang-Unit :: 
> Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException
>  (28440 of 28440)
>    TEST 'Clang-Unit :: 
> Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException'
>  FAILED 
>   Script:
>   --
>   
> /Users/thakis/src/llvm-project/out/gn/obj/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests
>  --gtest_filter=InterpreterTest.CatchException
>   --
>   Note: Google Test filter = InterpreterTest.CatchException
>   [==] Running 1 test from 1 test suite.
>   [--] Global test environment set-up.
>   [--] 1 test from InterpreterTest
>   [ RUN  ] InterpreterTest.CatchException
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   
>
> Please take a look.

It looks like we hit https://bugs.llvm.org/show_bug.cgi?id=49692

cc: @karies, @Hahnfeld


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

In D107049#2982224 , @thakis wrote:

> Thanks for fixing! Intel macs are happy now.
>
> But the test is still failing on arm macs: 
> http://45.33.8.238/macm1/17292/step_7.txt
>
>   FAIL: Clang-Unit :: 
> Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException
>  (28440 of 28440)
>    TEST 'Clang-Unit :: 
> Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException'
>  FAILED 
>   Script:
>   --
>   
> /Users/thakis/src/llvm-project/out/gn/obj/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests
>  --gtest_filter=InterpreterTest.CatchException
>   --
>   Note: Google Test filter = InterpreterTest.CatchException
>   [==] Running 1 test from 1 test suite.
>   [--] Global test environment set-up.
>   [--] 1 test from InterpreterTest
>   [ RUN  ] InterpreterTest.CatchException
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   
>
> Please take a look.

Yes, thanks for this information -- it fails also on hexagon so reverted it 
again :(


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Thanks for fixing! Intel macs are happy now.

But the test is still failing on arm macs: 
http://45.33.8.238/macm1/17292/step_7.txt

  FAIL: Clang-Unit :: 
Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException
 (28440 of 28440)
   TEST 'Clang-Unit :: 
Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException'
 FAILED 
  Script:
  --
  
/Users/thakis/src/llvm-project/out/gn/obj/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests
 --gtest_filter=InterpreterTest.CatchException
  --
  Note: Google Test filter = InterpreterTest.CatchException
  [==] Running 1 test from 1 test suite.
  [--] Global test environment set-up.
  [--] 1 test from InterpreterTest
  [ RUN  ] InterpreterTest.CatchException
  libunwind: malformed __unwind_info at 0x192029E3C bad second level page
  libunwind: malformed __unwind_info at 0x192029E3C bad second level page
  libunwind: malformed __unwind_info at 0x192029E3C bad second level page
  libunwind: malformed __unwind_info at 0x192029E3C bad second level page
  libunwind: malformed __unwind_info at 0x192029E3C bad second level page
  libunwind: malformed __unwind_info at 0x192029E3C bad second level page
  libunwind: malformed __unwind_info at 0x192029E3C bad second level page
  libunwind: malformed __unwind_info at 0x192029E3C bad second level page
  

Please take a look.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

> I did not find a good way to 'find back' the clang resource-dir and it seems 
> to be put in a constant place. The test needs to have a compiled and 
> interpreted parts -- it throws an exception from the interpreter land and 
> expects a compiled binary to be able to catch it. I am not sure if I know how 
> to do that in lit.

Maybe this could be a binary with a main() function instead of a unit test, and 
you pass the path to the resource dir and to clang-interpreter to it, and then 
that sets up an exception handler and execs clang-interpreter? Or it could stay 
mostly as-is except make it a binary instead of a test, and call it from lit 
from a `.test` file (and pass in resource dir). That'd be more in line what 
other clang tests do.

(See e.g. the `%resource_dir` substitution, set in 
llvm/utils/lit/lit/llvm/config.py, used in a few places.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

In D107049#2976603 , @thakis wrote:

> The test fails for me on macOS (normal cmake build):
>
>   % 
> tools/clang/unittests/Interpreter/ExceptionTests/ClangReplInterpreterExceptionTests
>   [==] Running 1 test from 1 test suite.
>   [--] Global test environment set-up.
>   [--] 1 test from InterpreterTest
>   [ RUN  ] InterpreterTest.CatchException
>   In file included from <<< inputs >>>:1:
>   input_line_0:2:10: fatal error: 'stdexcept' file not found
>   #include 
>^~~
>
> The reason is probably that C++ stdlib headers are part of the toolchain, not 
> the sysroot, on macOS. So self-built clang can't include libc++(abi) headers 
> without some hoops.
>
> Tests should generally be standalone though anyways. Can we remove these 
> includes and just throw some basic type?

Good point. I think I can avoid including stdexcept.

> Finally, hardcoding the path between unit test binary and the rest of the 
> build dir is fairly unusual. Can't this be a lit-style test that uses the 
> normal substitution logic we use in lit?

I did not find a good way to 'find back' the clang resource-dir and it seems to 
be put in a constant place. The test needs to have a compiled and interpreted 
parts -- it throws an exception from the interpreter land and expects a 
compiled binary to be able to catch it. I am not sure if I know how to do that 
in lit.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Also failing on the bots: 
https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/23343/execution/node/39/log/
 (that's for the original land, but from what I can tell nothing has changed in 
this regard for the reland, and I'm still seeing the same failure at head).

I'll revert this for now to unbreak mac bots.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.
Herald added a subscriber: ormris.

The test fails for me on macOS (normal cmake build):

  % 
tools/clang/unittests/Interpreter/ExceptionTests/ClangReplInterpreterExceptionTests
  [==] Running 1 test from 1 test suite.
  [--] Global test environment set-up.
  [--] 1 test from InterpreterTest
  [ RUN  ] InterpreterTest.CatchException
  In file included from <<< inputs >>>:1:
  input_line_0:2:10: fatal error: 'stdexcept' file not found
  #include 
   ^~~

The reason is probably that C++ stdlib headers are part of the toolchain, not 
the sysroot, on macOS. So self-built clang can't include libc++(abi) headers 
without some hoops.

Tests should generally be standalone though anyways. Can we remove these 
includes and just throw some basic type?

Finally, hardcoding the path between unit test binary and the rest of the build 
dir is fairly unusual. Can't this be a lit-style test that uses the normal 
substitution logic we use in lit?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG319ce9801174: [clang-repl] Re-implement clang-interpreter as 
a test case. (authored by v.g.vassilev).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D107049?vs=369729&id=369845#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

Files:
  clang/docs/ClangFormattedStatus.rst
  clang/examples/CMakeLists.txt
  clang/examples/clang-interpreter/CMakeLists.txt
  clang/examples/clang-interpreter/README.txt
  clang/examples/clang-interpreter/Test.cxx
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Misc/interpreter.c
  clang/test/lit.cfg.py
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -17,8 +17,6 @@
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
-#include "llvm/ADT/ArrayRef.h"
-
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- /dev/null
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -0,0 +1,121 @@
+//===- unittests/Interpreter/InterpreterExceptionTest.cpp -===//
+//
+// 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
+//
+//===--===//
+//
+// Unit tests for Clang's Interpreter library.
+//
+//===--===//
+
+#include "clang/Interpreter/Interpreter.h"
+
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclGroup.h"
+#include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ExecutionEngine/Orc/LLJIT.h"
+#include "llvm/Support/TargetSelect.h"
+
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+using Args = std::vector;
+static std::unique_ptr
+createInterpreter(const Args &ExtraArgs = {},
+  DiagnosticConsumer *Client = nullptr) {
+  Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
+  ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
+  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  if (Client)
+CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
+  return cantFail(clang::Interpreter::create(std::move(CI)));
+}
+
+// This function isn't referenced outside its translation unit, but it
+// can't use the "static" keyword because its address is used for
+// GetMainExecutable (since some platforms don't support taking the
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {
+  return llvm::sys::fs::getMainExecutable(Argv0, MainAddr);
+}
+
+static std::string MakeResourcesPath() {
+  // Dir is bin/ or lib/, depending on where BinaryPath is.
+  void *MainAddr = (void *)(intptr_t)GetExecutablePath;
+  std::string BinaryPath = GetExecutablePath(/*Argv0=*/nullptr, MainAddr);
+
+  // build/tools/clang/unittests/Interpreter/Executable -> build/
+  llvm::StringRef Dir = llvm::sys::path::parent_path(BinaryPath);
+
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  SmallString<128> P(Dir);
+  llvm::sys::path::append(P, Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+  CLANG_VERSION_STRING);
+
+  return std::string(P.str());
+}
+
+TEST(InterpreterTest, CatchException) {
+  llvm::InitializeNativeTarget();
+  llvm::InitializeNativeTargetAsmPrinter();
+
+  {
+auto J = llvm::orc::LLJITBuilder().create();
+if (!J) {
+  // The platform does not support JITs.
+  // We can't use llvm::consumeError as it needs t

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added inline comments.



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:101-105
+  // FIXME: Somehow when we build this test in release mode argc is not 0.
+  // printf("%d\n", argc);
+  // for (int I = 0; I < argc; ++I)
+  //   printf("arg[%d]='%s'\n", I, argv[I]);
+

rsmith wrote:
> Isn't this because you're passing no arguments to `main` when you call it 
> later in the test? You're not passing any arguments on line 123/124.
Ah, indeed. Thanks!



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:123-124
+  testing::internal::CaptureStdout();
+  auto Main = (int (*)(...))llvm::cantFail(Interp->getSymbolAddress("main"));
+  EXPECT_THROW(Main(), std::exception);
+  std::string CapturedStdOut = testing::internal::GetCapturedStdout();

rsmith wrote:
> I think this should probably be cast to `int(*)(int, const char**)` instead. 
> But the name `main` is special, and might not have its declared type, so 
> selecting a different function name would have less risk of weird behavior. 
> I'd also suggest you remove the parameters if you're not going to use them.
Fixed. The past intent was to keep it as close as possible to the original 
example.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 369729.
v.g.vassilev marked 3 inline comments as done.
v.g.vassilev added a comment.

Address comments.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

Files:
  clang/docs/ClangFormattedStatus.rst
  clang/examples/CMakeLists.txt
  clang/examples/clang-interpreter/CMakeLists.txt
  clang/examples/clang-interpreter/README.txt
  clang/examples/clang-interpreter/Test.cxx
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Misc/interpreter.c
  clang/test/lit.cfg.py
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -17,8 +17,6 @@
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
-#include "llvm/ADT/ArrayRef.h"
-
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- /dev/null
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -0,0 +1,121 @@
+//===- unittests/Interpreter/InterpreterExceptionTest.cpp -===//
+//
+// 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
+//
+//===--===//
+//
+// Unit tests for Clang's Interpreter library.
+//
+//===--===//
+
+#include "clang/Interpreter/Interpreter.h"
+
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclGroup.h"
+#include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ExecutionEngine/Orc/LLJIT.h"
+#include "llvm/Support/TargetSelect.h"
+
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+using Args = std::vector;
+static std::unique_ptr
+createInterpreter(const Args &ExtraArgs = {},
+  DiagnosticConsumer *Client = nullptr) {
+  Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
+  ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
+  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  if (Client)
+CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
+  return cantFail(clang::Interpreter::create(std::move(CI)));
+}
+
+// This function isn't referenced outside its translation unit, but it
+// can't use the "static" keyword because its address is used for
+// GetMainExecutable (since some platforms don't support taking the
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {
+  return llvm::sys::fs::getMainExecutable(Argv0, MainAddr);
+}
+
+static std::string MakeResourcesPath() {
+  // Dir is bin/ or lib/, depending on where BinaryPath is.
+  void *MainAddr = (void *)(intptr_t)GetExecutablePath;
+  std::string BinaryPath = GetExecutablePath(/*Argv0=*/nullptr, MainAddr);
+
+  // build/tools/clang/unittests/Interpreter/Executable -> build/
+  llvm::StringRef Dir = llvm::sys::path::parent_path(BinaryPath);
+
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  SmallString<128> P(Dir);
+  llvm::sys::path::append(P, Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+  CLANG_VERSION_STRING);
+
+  return std::string(P.str());
+}
+
+TEST(InterpreterTest, CatchException) {
+  llvm::InitializeNativeTarget();
+  llvm::InitializeNativeTargetAsmPrinter();
+
+  {
+auto J = llvm::orc::LLJITBuilder().create();
+if (!J) {
+  // The platform does not support JITs.
+  // We can't use llvm::consumeError as it needs typeinfo for ErrorInfoBase.
+  auto E = J.takeError();
+  (void)E;
+  return;
+}
+  }
+  const char ExceptionCode[] =
+  R"(
+#include 
+#include 
+
+static void ThrowerAnError(const char* Name) {
+  throw std::runtime_error(Name);
+}
+
+ex

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:73-76
+#ifdef _MSC_VER
+// Tell the windows linker to export the type_info symbol required by 
exceptions
+#pragma comment(linker, "/export:??_7type_info@@6B@")
+#endif // _MSC_VER

Presumably this is redundant now we don't run the test on Windows?



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:101-105
+  // FIXME: Somehow when we build this test in release mode argc is not 0.
+  // printf("%d\n", argc);
+  // for (int I = 0; I < argc; ++I)
+  //   printf("arg[%d]='%s'\n", I, argv[I]);
+

Isn't this because you're passing no arguments to `main` when you call it later 
in the test? You're not passing any arguments on line 123/124.



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:123-124
+  testing::internal::CaptureStdout();
+  auto Main = (int (*)(...))llvm::cantFail(Interp->getSymbolAddress("main"));
+  EXPECT_THROW(Main(), std::exception);
+  std::string CapturedStdOut = testing::internal::GetCapturedStdout();

I think this should probably be cast to `int(*)(int, const char**)` instead. 
But the name `main` is special, and might not have its declared type, so 
selecting a different function name would have less risk of weird behavior. I'd 
also suggest you remove the parameters if you're not going to use them.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 367114.
v.g.vassilev added a subscriber: sgraenitz.
v.g.vassilev added a comment.

Disable the case exception test of windows.

cc: @sgraenitz


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

Files:
  clang/docs/ClangFormattedStatus.rst
  clang/examples/CMakeLists.txt
  clang/examples/clang-interpreter/CMakeLists.txt
  clang/examples/clang-interpreter/README.txt
  clang/examples/clang-interpreter/Test.cxx
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Misc/interpreter.c
  clang/test/lit.cfg.py
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -17,8 +17,6 @@
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
-#include "llvm/ADT/ArrayRef.h"
-
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- /dev/null
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -0,0 +1,129 @@
+//===- unittests/Interpreter/InterpreterExceptionTest.cpp -===//
+//
+// 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
+//
+//===--===//
+//
+// Unit tests for Clang's Interpreter library.
+//
+//===--===//
+
+#include "clang/Interpreter/Interpreter.h"
+
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclGroup.h"
+#include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ExecutionEngine/Orc/LLJIT.h"
+#include "llvm/Support/TargetSelect.h"
+
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+using Args = std::vector;
+static std::unique_ptr
+createInterpreter(const Args &ExtraArgs = {},
+  DiagnosticConsumer *Client = nullptr) {
+  Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
+  ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
+  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  if (Client)
+CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
+  return cantFail(clang::Interpreter::create(std::move(CI)));
+}
+
+// This function isn't referenced outside its translation unit, but it
+// can't use the "static" keyword because its address is used for
+// GetMainExecutable (since some platforms don't support taking the
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {
+  return llvm::sys::fs::getMainExecutable(Argv0, MainAddr);
+}
+
+static std::string MakeResourcesPath() {
+  // Dir is bin/ or lib/, depending on where BinaryPath is.
+  void *MainAddr = (void *)(intptr_t)GetExecutablePath;
+  std::string BinaryPath = GetExecutablePath(/*Argv0=*/nullptr, MainAddr);
+
+  // build/tools/clang/unittests/Interpreter/Executable -> build/
+  llvm::StringRef Dir = llvm::sys::path::parent_path(BinaryPath);
+
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  SmallString<128> P(Dir);
+  llvm::sys::path::append(P, Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+  CLANG_VERSION_STRING);
+
+  return std::string(P.str());
+}
+
+#ifdef _MSC_VER
+// Tell the windows linker to export the type_info symbol required by exceptions
+#pragma comment(linker, "/export:??_7type_info@@6B@")
+#endif // _MSC_VER
+TEST(InterpreterTest, CatchException) {
+  llvm::InitializeNativeTarget();
+  llvm::InitializeNativeTargetAsmPrinter();
+
+  {
+auto J = llvm::orc::LLJITBuilder().create();
+if (!J) {
+  // The platform does not support JITs.
+  // We can't use llvm::consumeError as it needs typeinfo for ErrorInfoBase.
+  auto E = J.t

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 367015.
v.g.vassilev added a comment.

Try fix the win pre-merge bot. Clang-format.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

Files:
  clang/docs/ClangFormattedStatus.rst
  clang/examples/CMakeLists.txt
  clang/examples/clang-interpreter/CMakeLists.txt
  clang/examples/clang-interpreter/README.txt
  clang/examples/clang-interpreter/Test.cxx
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Misc/interpreter.c
  clang/test/lit.cfg.py
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -17,8 +17,6 @@
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
-#include "llvm/ADT/ArrayRef.h"
-
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- /dev/null
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -0,0 +1,129 @@
+//===- unittests/Interpreter/InterpreterExceptionTest.cpp -===//
+//
+// 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
+//
+//===--===//
+//
+// Unit tests for Clang's Interpreter library.
+//
+//===--===//
+
+#include "clang/Interpreter/Interpreter.h"
+
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclGroup.h"
+#include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ExecutionEngine/Orc/LLJIT.h"
+#include "llvm/Support/TargetSelect.h"
+
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+using Args = std::vector;
+static std::unique_ptr
+createInterpreter(const Args &ExtraArgs = {},
+  DiagnosticConsumer *Client = nullptr) {
+  Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
+  ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
+  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  if (Client)
+CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
+  return cantFail(clang::Interpreter::create(std::move(CI)));
+}
+
+// This function isn't referenced outside its translation unit, but it
+// can't use the "static" keyword because its address is used for
+// GetMainExecutable (since some platforms don't support taking the
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {
+  return llvm::sys::fs::getMainExecutable(Argv0, MainAddr);
+}
+
+static std::string MakeResourcesPath() {
+  // Dir is bin/ or lib/, depending on where BinaryPath is.
+  void *MainAddr = (void *)(intptr_t)GetExecutablePath;
+  std::string BinaryPath = GetExecutablePath(/*Argv0=*/nullptr, MainAddr);
+
+  // build/tools/clang/unittests/Interpreter/Executable -> build/
+  llvm::StringRef Dir = llvm::sys::path::parent_path(BinaryPath);
+
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  SmallString<128> P(Dir);
+  llvm::sys::path::append(P, Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+  CLANG_VERSION_STRING);
+
+  return std::string(P.str());
+}
+
+#ifdef _MSC_VER
+// Tell the windows linker to export the type_info symbol required by exceptions
+#pragma comment(linker, "/export:??_7type_info@@6B@")
+#endif // _MSC_VER
+TEST(InterpreterTest, CatchException) {
+  llvm::InitializeNativeTarget();
+  llvm::InitializeNativeTargetAsmPrinter();
+
+  {
+auto J = llvm::orc::LLJITBuilder().create();
+if (!J) {
+  // The platform does not support JITs.
+  // We can't use llvm::consumeError as it needs typeinfo for ErrorInfoBase.
+  auto E = J.takeError();
+  (void)E;
+  return;
+}
+  }
+  c

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 366978.
v.g.vassilev added a comment.

Split the exception handling test into a separate unittest and compile it with 
exceptions on.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

Files:
  clang/docs/ClangFormattedStatus.rst
  clang/examples/CMakeLists.txt
  clang/examples/clang-interpreter/CMakeLists.txt
  clang/examples/clang-interpreter/README.txt
  clang/examples/clang-interpreter/Test.cxx
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Misc/interpreter.c
  clang/test/lit.cfg.py
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt
  clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -17,8 +17,6 @@
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
-#include "llvm/ADT/ArrayRef.h"
-
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
Index: clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
===
--- /dev/null
+++ clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -0,0 +1,125 @@
+//===- unittests/Interpreter/InterpreterExceptionTest.cpp -===//
+//
+// 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
+//
+//===--===//
+//
+// Unit tests for Clang's Interpreter library.
+//
+//===--===//
+
+#include "clang/Interpreter/Interpreter.h"
+
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclGroup.h"
+#include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ExecutionEngine/Orc/LLJIT.h"
+#include "llvm/Support/TargetSelect.h"
+
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+using Args = std::vector;
+static std::unique_ptr
+createInterpreter(const Args &ExtraArgs = {},
+  DiagnosticConsumer *Client = nullptr) {
+  Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
+  ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
+  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  if (Client)
+CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
+  return cantFail(clang::Interpreter::create(std::move(CI)));
+}
+
+// This function isn't referenced outside its translation unit, but it
+// can't use the "static" keyword because its address is used for
+// GetMainExecutable (since some platforms don't support taking the
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {
+  return llvm::sys::fs::getMainExecutable(Argv0, MainAddr);
+}
+
+static std::string MakeResourcesPath() {
+  // Dir is bin/ or lib/, depending on where BinaryPath is.
+  void *MainAddr = (void *)(intptr_t)GetExecutablePath;
+  std::string BinaryPath = GetExecutablePath(/*Argv0=*/nullptr, MainAddr);
+
+  // build/tools/clang/unittests/Interpreter/Executable -> build/
+  llvm::StringRef Dir = llvm::sys::path::parent_path(BinaryPath);
+
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  SmallString<128> P(Dir);
+  llvm::sys::path::append(P, Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+  CLANG_VERSION_STRING);
+
+  return std::string(P.str());
+}
+
+TEST(InterpreterTest, CatchException) {
+  llvm::InitializeNativeTarget();
+  llvm::InitializeNativeTargetAsmPrinter();
+
+  {
+auto J = llvm::orc::LLJITBuilder().create();
+if (!J) {
+  // The platform does not support JITs.
+  // We can't use llvm::consumeError as it needs typeinfo for ErrorInfoBase.
+  auto E = J.takeError();
+  (void) E;
+  return;
+}
+  }
+  const char ExceptionCode[] =
+  R"(
+#include 
+#include 
+
+static void ThrowerAnError(const char* Name) {
+  throw std

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 365134.
v.g.vassilev added a comment.

rebase


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

Files:
  clang/docs/ClangFormattedStatus.rst
  clang/examples/CMakeLists.txt
  clang/examples/clang-interpreter/CMakeLists.txt
  clang/examples/clang-interpreter/README.txt
  clang/examples/clang-interpreter/Test.cxx
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Misc/interpreter.c
  clang/test/lit.cfg.py
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -14,10 +14,14 @@
 
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclGroup.h"
+#include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/ExecutionEngine/Orc/LLJIT.h"
+#include "llvm/Support/TargetSelect.h"
 
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -53,6 +57,92 @@
   EXPECT_EQ(1U, DeclsSize(R2.TUPart));
 }
 
+// This function isn't referenced outside its translation unit, but it
+// can't use the "static" keyword because its address is used for
+// GetMainExecutable (since some platforms don't support taking the
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {
+  return llvm::sys::fs::getMainExecutable(Argv0, MainAddr);
+}
+
+static std::string MakeResourcesPath() {
+  // Dir is bin/ or lib/, depending on where BinaryPath is.
+  void *MainAddr = (void *)(intptr_t)GetExecutablePath;
+  std::string BinaryPath = GetExecutablePath(/*Argv0=*/nullptr, MainAddr);
+
+  // build/tools/clang/unittests/Interpreter/Executable -> build/
+  llvm::StringRef Dir = llvm::sys::path::parent_path(BinaryPath);
+
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  SmallString<128> P(Dir);
+  llvm::sys::path::append(P, Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+  CLANG_VERSION_STRING);
+
+  return std::string(P.str());
+}
+
+#ifdef _MSC_VER
+// Tell the windows linker to export the type_info symbol required by exceptions
+#pragma comment(linker, "/export:??_7type_info@@6B@")
+#endif // _MSC_VER
+TEST(InterpreterTest, CatchException) {
+  llvm::InitializeNativeTarget();
+  llvm::InitializeNativeTargetAsmPrinter();
+
+  {
+auto J = llvm::orc::LLJITBuilder().create();
+if (!J) {
+  // The platform does not support JITs.
+  llvm::consumeError(J.takeError());
+  return;
+}
+  }
+  const char ExceptionCode[] =
+  R"(
+#include 
+#include 
+
+static void ThrowerAnError(const char* Name) {
+  throw std::runtime_error(Name);
+}
+
+int main(int argc, const char** argv) {
+  // FIXME: Somehow when we build this test in release mode argc is not 0.
+  // printf("%d\n", argc);
+  // for (int I = 0; I < argc; ++I)
+  //   printf("arg[%d]='%s'\n", I, argv[I]);
+
+  try {
+ThrowerAnError("In JIT");
+  } catch (const std::exception& E) {
+printf("Caught: '%s'\n", E.what());
+  } catch (...) {
+printf("Unknown exception\n");
+  }
+  ThrowerAnError("From JIT");
+  return 0;
+}
+)";
+  std::string ResourceDir = MakeResourcesPath();
+  std::unique_ptr Interp =
+  createInterpreter({"-resource-dir", ResourceDir.c_str()});
+  // Adjust the resource-dir
+  llvm::cantFail(Interp->ParseAndExecute(ExceptionCode));
+#if !defined(NDEBUG) && GTEST_HAS_DEATH_TEST && !defined(_WIN32)
+  testing::internal::CaptureStdout();
+  auto Main = (int (*)(...))llvm::cantFail(Interp->getSymbolAddress("main"));
+  // Compiling this file with exceptions on is problematic on some platforms.
+  // Instead we expect std::terminate to be called upon thrown exception.
+  EXPECT_DEATH(Main(), "terminate called after throwing an instance of '.*'");
+#endif
+  std::string CapturedStdOut = testing::internal::GetCapturedStdout();
+  EXPECT_EQ(CapturedStdOut, "Caught: 'In JIT'\n");
+}
+
 static std::string DeclToString(Decl *D) {
   return llvm::cast(D)->getQualifiedNameAsString();
 }
Index: clang/unittests/Interpreter/CMakeLists.txt
===
--- clang/unittests/Interpreter/CMakeLists.txt
+++ clang/unittests/Interpreter/CMakeLists.txt
@@ -12,3 +12,4 @@
   clangInterpreter
   clangFrontend
   )
+add_dependencies(

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 365005.
v.g.vassilev added a comment.

Try to appease the windows pre-merge bot.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

Files:
  clang/docs/ClangFormattedStatus.rst
  clang/examples/CMakeLists.txt
  clang/examples/clang-interpreter/CMakeLists.txt
  clang/examples/clang-interpreter/README.txt
  clang/examples/clang-interpreter/Test.cxx
  clang/examples/clang-interpreter/main.cpp
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Misc/interpreter.c
  clang/test/lit.cfg.py
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -14,10 +14,14 @@
 
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclGroup.h"
+#include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/ExecutionEngine/Orc/LLJIT.h"
+#include "llvm/Support/TargetSelect.h"
 
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -53,6 +57,92 @@
   EXPECT_EQ(1U, DeclsSize(R2.TUPart));
 }
 
+// This function isn't referenced outside its translation unit, but it
+// can't use the "static" keyword because its address is used for
+// GetMainExecutable (since some platforms don't support taking the
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {
+  return llvm::sys::fs::getMainExecutable(Argv0, MainAddr);
+}
+
+static std::string MakeResourcesPath() {
+  // Dir is bin/ or lib/, depending on where BinaryPath is.
+  void *MainAddr = (void *)(intptr_t)GetExecutablePath;
+  std::string BinaryPath = GetExecutablePath(/*Argv0=*/nullptr, MainAddr);
+
+  // build/tools/clang/unittests/Interpreter/Executable -> build/
+  llvm::StringRef Dir = llvm::sys::path::parent_path(BinaryPath);
+
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  SmallString<128> P(Dir);
+  llvm::sys::path::append(P, Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+  CLANG_VERSION_STRING);
+
+  return std::string(P.str());
+}
+
+#ifdef _MSC_VER
+// Tell the windows linker to export the type_info symbol required by exceptions
+#pragma comment(linker, "/export:??_7type_info@@6B@")
+#endif // _MSC_VER
+TEST(InterpreterTest, CatchException) {
+  llvm::InitializeNativeTarget();
+  llvm::InitializeNativeTargetAsmPrinter();
+
+  {
+auto J = llvm::orc::LLJITBuilder().create();
+if (!J) {
+  // The platform does not support JITs.
+  llvm::consumeError(J.takeError());
+  return;
+}
+  }
+  const char ExceptionCode[] =
+  R"(
+#include 
+#include 
+
+static void ThrowerAnError(const char* Name) {
+  throw std::runtime_error(Name);
+}
+
+int main(int argc, const char** argv) {
+  // FIXME: Somehow when we build this test in release mode argc is not 0.
+  // printf("%d\n", argc);
+  // for (int I = 0; I < argc; ++I)
+  //   printf("arg[%d]='%s'\n", I, argv[I]);
+
+  try {
+ThrowerAnError("In JIT");
+  } catch (const std::exception& E) {
+printf("Caught: '%s'\n", E.what());
+  } catch (...) {
+printf("Unknown exception\n");
+  }
+  ThrowerAnError("From JIT");
+  return 0;
+}
+)";
+  std::string ResourceDir = MakeResourcesPath();
+  std::unique_ptr Interp =
+  createInterpreter({"-resource-dir", ResourceDir.c_str()});
+  // Adjust the resource-dir
+  llvm::cantFail(Interp->ParseAndExecute(ExceptionCode));
+#if !defined(NDEBUG) && GTEST_HAS_DEATH_TEST && !defined(_WIN32)
+  testing::internal::CaptureStdout();
+  auto Main = (int (*)(...))llvm::cantFail(Interp->getSymbolAddress("main"));
+  // Compiling this file with exceptions on is problematic on some platforms.
+  // Instead we expect std::terminate to be called upon thrown exception.
+  EXPECT_DEATH(Main(), "terminate called after throwing an instance of '.*'");
+#endif
+  std::string CapturedStdOut = testing::internal::GetCapturedStdout();
+  EXPECT_EQ(CapturedStdOut, "Caught: 'In JIT'\n");
+}
+
 static std::string DeclToString(Decl *D) {
   return llvm::cast(D)->getQualifiedNameAsString();
 }
Index: clang/unittests/Interpreter/CMakeLists.txt
===
--- clang/unittests/Interpreter/CMakeLists.txt
+++ clang/unittests/Interpreter/CMakeLists.txt

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev updated this revision to Diff 363289.
v.g.vassilev added a comment.

Try to fix the issues reported by the pre-merge-checks. clang-format.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

Files:
  clang/docs/ClangFormattedStatus.rst
  clang/examples/CMakeLists.txt
  clang/examples/clang-interpreter/CMakeLists.txt
  clang/examples/clang-interpreter/README.txt
  clang/examples/clang-interpreter/Test.cxx
  clang/examples/clang-interpreter/main.cpp
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Misc/interpreter.c
  clang/test/lit.cfg.py
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -14,10 +14,14 @@
 
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclGroup.h"
+#include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/ExecutionEngine/Orc/LLJIT.h"
+#include "llvm/Support/TargetSelect.h"
 
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -53,6 +57,92 @@
   EXPECT_EQ(1U, DeclsSize(R2.TUPart));
 }
 
+// This function isn't referenced outside its translation unit, but it
+// can't use the "static" keyword because its address is used for
+// GetMainExecutable (since some platforms don't support taking the
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {
+  return llvm::sys::fs::getMainExecutable(Argv0, MainAddr);
+}
+
+static std::string MakeResourcesPath() {
+  // Dir is bin/ or lib/, depending on where BinaryPath is.
+  void *MainAddr = (void *)(intptr_t)GetExecutablePath;
+  std::string BinaryPath = GetExecutablePath(/*Argv0=*/nullptr, MainAddr);
+
+  // build/tools/clang/unittests/Interpreter/Executable -> build/
+  llvm::StringRef Dir = llvm::sys::path::parent_path(BinaryPath);
+
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  SmallString<128> P(Dir);
+  llvm::sys::path::append(P, Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+  CLANG_VERSION_STRING);
+
+  return std::string(P.str());
+}
+
+#ifdef _MSC_VER
+// Tell the windows linker to export the type_info symbol required by exceptions
+#pragma comment(linker, "/export:??_7type_info@@6B@")
+#endif // _MSC_VER
+TEST(InterpreterTest, CatchException) {
+  llvm::InitializeNativeTarget();
+  llvm::InitializeNativeTargetAsmPrinter();
+
+  {
+auto J = llvm::orc::LLJITBuilder().create();
+if (!J) {
+  // The platform does not support JITs.
+  llvm::consumeError(J.takeError());
+  return;
+}
+  }
+  const char ExceptionCode[] =
+  R"(
+#include 
+#include 
+
+static void ThrowerAnError(const char* Name) {
+  throw std::runtime_error(Name);
+}
+
+int main(int argc, const char** argv) {
+  // FIXME: Somehow when we build this test in release mode argc is not 0.
+  // printf("%d\n", argc);
+  // for (int I = 0; I < argc; ++I)
+  //   printf("arg[%d]='%s'\n", I, argv[I]);
+
+  try {
+ThrowerAnError("In JIT");
+  } catch (const std::exception& E) {
+printf("Caught: '%s'\n", E.what());
+  } catch (...) {
+printf("Unknown exception\n");
+  }
+  ThrowerAnError("From JIT");
+  return 0;
+}
+)";
+  std::string ResourceDir = MakeResourcesPath();
+  std::unique_ptr Interp =
+  createInterpreter({"-resource-dir", ResourceDir.c_str()});
+  // Adjust the resource-dir
+  llvm::cantFail(Interp->ParseAndExecute(ExceptionCode));
+#if !defined(NDEBUG) && GTEST_HAS_DEATH_TEST
+  testing::internal::CaptureStdout();
+  auto Main = (int (*)(...))llvm::cantFail(Interp->getSymbolAddress("main"));
+  // Compiling this file with exceptions on is problematic on some platforms.
+  // Instead we expect std::terminate to be called upon thrown exception.
+  EXPECT_DEATH(Main(), "terminate called after throwing an instance of '.*'");
+  std::string CapturedStdOut = testing::internal::GetCapturedStdout();
+  EXPECT_EQ(CapturedStdOut, "Caught: 'In JIT'\n");
+#endif
+}
+
 static std::string DeclToString(Decl *D) {
   return llvm::cast(D)->getQualifiedNameAsString();
 }
Index: clang/unittests/Interpreter/CMakeLists.txt
===
--- clang/unittests/Interpreter/CMakeLists.txt
+++ clang/unittests/Interpreter/CMakeL

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added inline comments.



Comment at: clang/unittests/Interpreter/InterpreterTest.cpp:64
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {

rsmith wrote:
> I don't follow why this can't be static. Is there some problem with using the 
> address of this function if it's static?
That's a standard comment for each `GetExecutablePath` and I copy pasted it as 
done elsewhere. That requirement might be lifted in recent systems but I do not 
know the platform coverage to check.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith accepted this revision.
rsmith added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/unittests/Interpreter/InterpreterTest.cpp:64
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {

I don't follow why this can't be static. Is there some problem with using the 
address of this function if it's static?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a reviewer: rnk.
v.g.vassilev added a subscriber: rnk.
v.g.vassilev added inline comments.



Comment at: clang/unittests/Interpreter/InterpreterTest.cpp:134
+  // Instead we expect std::terminate to be called upon thrown exception.
+  EXPECT_DEATH(Main(), "terminate called after throwing an instance of '.*'");
+  std::string CapturedStdOut = testing::internal::GetCapturedStdout();

@rnk, would that test here be fine for both win32 and win64. Sorry for asking 
but I do not have an easy access to a Windows machine.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Lang Hames via Phabricator via cfe-commits]

lhames added a comment.

LGTM, but a clang dev should probably check this out too.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev created this revision.
v.g.vassilev added reviewers: rsmith, teemperor, lhames, bkramer.
Herald added subscribers: mstorsjo, mgorny.
v.g.vassilev requested review of this revision.

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.


Repository:
  rC Clang

https://reviews.llvm.org/D107049

Files:
  clang/docs/ClangFormattedStatus.rst
  clang/examples/CMakeLists.txt
  clang/examples/clang-interpreter/CMakeLists.txt
  clang/examples/clang-interpreter/README.txt
  clang/examples/clang-interpreter/Test.cxx
  clang/examples/clang-interpreter/main.cpp
  clang/include/clang/Interpreter/Interpreter.h
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Misc/interpreter.c
  clang/test/lit.cfg.py
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -14,10 +14,14 @@
 
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclGroup.h"
+#include "clang/Basic/Version.h"
+#include "clang/Config/config.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/TextDiagnosticPrinter.h"
 
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/ExecutionEngine/Orc/LLJIT.h"
+#include "llvm/Support/TargetSelect.h"
 
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -53,6 +57,86 @@
   EXPECT_EQ(1U, DeclsSize(R2.TUPart));
 }
 
+// This function isn't referenced outside its translation unit, but it
+// can't use the "static" keyword because its address is used for
+// GetMainExecutable (since some platforms don't support taking the
+// address of main, and some platforms can't implement GetMainExecutable
+// without being given the address of a function in the main executable).
+std::string GetExecutablePath(const char *Argv0, void *MainAddr) {
+  return llvm::sys::fs::getMainExecutable(Argv0, MainAddr);
+}
+
+static std::string MakeResourcesPath() {
+  // Dir is bin/ or lib/, depending on where BinaryPath is.
+  void *MainAddr = (void*) (intptr_t) GetExecutablePath;
+  std::string BinaryPath = GetExecutablePath(/*Argv0=*/nullptr, MainAddr);
+
+  // build/tools/clang/unittests/Interpreter/Executable -> build/
+  llvm::StringRef Dir = llvm::sys::path::parent_path(BinaryPath);
+
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  Dir = llvm::sys::path::parent_path(Dir);
+  SmallString<128> P(Dir);
+  llvm::sys::path::append(P, Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+  CLANG_VERSION_STRING);
+
+  return std::string(P.str());
+}
+
+TEST(InterpreterTest, CatchException) {
+  llvm::InitializeNativeTarget();
+  llvm::InitializeNativeTargetAsmPrinter();
+
+  {
+auto J = llvm::orc::LLJITBuilder().create();
+if (!J) {
+  // The platform does not support JITs.
+  llvm::consumeError(J.takeError());
+  return;
+}
+  }
+  const char ExceptionCode[] =
+R"(
+#include 
+#include 
+
+static void ThrowerAnError(const char* Name) {
+  throw std::runtime_error(Name);
+}
+
+int main(int argc, const char** argv) {
+  for (int I = 0; I < argc; ++I)
+   printf("arg[%d]='%s'\n", I, argv[I]);
+
+  try {
+ThrowerAnError("In JIT");
+  } catch (const std::exception& E) {
+printf("Caught: '%s'\n", E.what());
+  } catch (...) {
+printf("Unknown exception\n");
+  }
+  ThrowerAnError("From JIT");
+  return 0;
+}
+)";
+  std::string ResourceDir = MakeResourcesPath();
+  std::unique_ptr Interp =
+  createInterpreter({"-resource-dir", ResourceDir.c_str()});
+  // Adjust the resource-dir
+  llvm::cantFail(Interp->ParseAndExecute(ExceptionCode));
+#if !defined(NDEBUG) && GTEST_HAS_DEATH_TEST
+  testing::internal::CaptureStdout();
+  auto Main = (int (*)(...))llvm::cantFail(Interp->getSymbolAddress("main"));
+  // Compiling this file with exceptions on is problematic on some platforms.
+  // Instead we expect std::terminate to be called upon thrown exception.
+  EXPECT_DEATH(Main(), "terminate called after throwing an instance of '.*'");
+  std::string CapturedStdOut = testing::internal::GetCapturedStdout();
+  EXPECT_EQ(CapturedStdOut, "Caught: 'In JIT'\n");
+#endif
+}
+
 static std::string DeclToString(Decl *D) {
   return llvm::cast(D)->getQualifiedNameAsString();
 }
Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -71,7 +71,6 @@
 
 if config.clang_examples:
 config.available_features.add('examples')