Re: [lldb-dev] [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge commits
On 1 Feb 2019, at 22:48, Peter Wu via cfe-dev wrote: > > On caveat is that the test coverage would be limited or else the build > times would be very long. There are quite some builders for various > projects (llvm, cfe, compiler-rt, etc.) on a lot of different platforms > and targets (Linux, macOS, Windows, Android, etc.). > > With limited resources, Arthur's suggestion seems workable to me: > - Enable pre-commit testing of few configurations (in parallel). > - Encourage developers to wait for tests to pass before pushing changes. > - Do not block hard to avoid a situation where unrelated changes > (commits or build environment) cause failures. GitHub does let you block merges (by anyone who isn’t an administrator) of PRs that don’t meet certain requirements. For one project, we have it set up so that you need to have at least one reviewer saying approved, you have to have signed the CLA, and you have to pass all of the CI checks. It’s then easy to set up automatic merging when all of the prerequisites are met (you can get a notification and process it automatically). We allow self approval for small changes (not automatically enforced, this is a judgement call, but you can remove people who abuse it from the team quite easily and then they can’t approve changes). I’ve found it leads to a very nice workflow: developers aren’t in the loop for merges, they just prepare something that they think works, submit it, and get on with something else. If you’re lucky, someone approves it and you pass CI first go, then everything is fine. Reviewers can wait until CI is finished and not bother looking for things that are going to break. If the change introduces new tests, reviewers know that those tests are passing. If you broke a platform that you don’t test on locally, you get notified but no one else is spammed with breakage reports. Once you’ve fixed it, you get a review, and make any changes. The master branch is always buildable and passing CI. If your changes break CI, you don’t have a race to fix things before someone reverts your change, you just fix things in the PR and wait for it to be automatically merged. David ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged
On 24 Jan 2019, at 21:25, Dimitry Andric via Release-testers wrote: > > On 24 Jan 2019, at 20:34, Michał Górny wrote: >> >> On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers wrote: >>> On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers >>> wrote: 8.0.0-rc1 was just tagged (from the branch at r351980). ... > Yes, I'm attempting again with this diff applied: > > --- llvm.src/projects/compiler-rt/cmake/config-ix.cmake > +++ llvm.src/projects/compiler-rt/cmake/config-ix.cmake > @@ -118,6 +118,7 @@ check_library_exists(dl dlopen "" COMPIL > check_library_exists(rt shm_open "" COMPILER_RT_HAS_LIBRT) > check_library_exists(m pow "" COMPILER_RT_HAS_LIBM) > check_library_exists(pthread pthread_create "" COMPILER_RT_HAS_LIBPTHREAD) > +check_library_exists(execinfo backtrace "" COMPILER_RT_HAS_LIBEXECINFO) > > # Look for terminfo library, used in unittests that depend on LLVMSupport. > if(LLVM_ENABLE_TERMINFO) > --- llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt > +++ llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt > @@ -71,13 +71,14 @@ if (NOT APPLE) > endforeach() > > # We also add the actual libraries to link as dependencies. > -list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport > -lLLVMTestingSupport) > +list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport > -lLLVMDemangle -lLLVMTestingSupport) > endif() > > append_list_if(COMPILER_RT_HAS_LIBM -lm XRAY_UNITTEST_LINK_FLAGS) > append_list_if(COMPILER_RT_HAS_LIBRT -lrt XRAY_UNITTEST_LINK_FLAGS) > append_list_if(COMPILER_RT_HAS_LIBDL -ldl XRAY_UNITTEST_LINK_FLAGS) > append_list_if(COMPILER_RT_HAS_LIBPTHREAD -pthread XRAY_UNITTEST_LINK_FLAGS) > + append_list_if(COMPILER_RT_HAS_LIBEXECINFO -lexecinfo > XRAY_UNITTEST_LINK_FLAGS) > endif() > > macro(add_xray_unittest testname) Meanwhile, this diff was applied, but I had little time to look at the tests again. As I mentioned in my previous email, I saw many tests failing with an Asan:DEADLYSIGNAL error, which kept on endlessly repeating, until my log files filled up. This is specifically happening during the dynamic ASan tests, e.g. Asan-x86_64-calls-Dynamic-Test and Asan-x86_64-inline-Dynamic-Test. Running these in gdb shows that it gets into an endless recursion: Starting program: /home/dim/obj/llvm-trunk-r352660/projects/compiler-rt/lib/asan/tests/dynamic/Asan-x86_64-inline-Dynamic-Test Program received signal SIGSEGV, Segmentation fault. 0x00080097bff1 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 408 reinterpret_cast(AsanTSDGet()); (gdb) bt #0 0x00080097bff1 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #1 0x0008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #2 0x000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #3 0x00080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #4 0x0008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #5 0x000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #6 0x00080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #7 0x0008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #8 0x000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #9 0x00080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #10 0x0008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #11 0x000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #12 0x00080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 #13 0x0008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107 #14 0x000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68 #15 0x00080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408 [...goes on until gdb crashes :)...] The _
