Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-09-01T09:12:37+00:00 2019-09-01T09:12:37+00:00 Raphael Isemann teemperor@gmail.com 2019-09-01T09:12:37+00:00 urn:sha1:29872606d220420d53fde7cc5e3bea15f8da62e7 Summary: As discussed on lldb-dev, this patch moves some LLDB tests into a hierarchy that more closely resembles the commands we use in the LLDB interpreter. This patch should only move tests that use the command interpreter and shouldn't touch any tests that primarily test the SB API. Reviewers: #lldb, jfb, JDevlieghere Reviewed By: #lldb, JDevlieghere Subscribers: dexonsmith, arphaman, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67033 llvm-svn: 370605 2019-07-25T20:27:40+00:00 Michal Gorny mgorny@gentoo.org 2019-07-25T20:27:40+00:00 urn:sha1:e1c159e86ac2f109d0d4d9342721ce78532660cf Mark the process as stopped when SIGSTOP arrives. This is necessary for lldb-server to generate correct response to 'process interrupt', and therefore to prevent the whole stack crashing when process is stopped. Thanks to Pavel Labath for the tip. Differential Revision: https://reviews.llvm.org/D65289 llvm-svn: 367047 2019-03-04T16:54:06+00:00 Michal Gorny mgorny@gentoo.org 2019-03-04T16:54:06+00:00 urn:sha1:de11105d2ece076e9d8dcfb01286643e81af8922 Add a convenience 'expectedFailureNetBSD' decorator and mark all tests currently failing on NetBSD with it. Also skip a few tests that hang the test suite. This should establish a baseline for the test suite and get us closer to enabling tests on buildbot. This will help us catch regressions while we still have a lot of work to do to get tests working. It seems that there are also some flaky tests. I am going to address them later on. Differential Revision: https://reviews.llvm.org/D58527 llvm-svn: 355320 2017-07-06T18:06:25+00:00 Jim Ingham jingham@apple.com 2017-07-06T18:06:25+00:00 urn:sha1:19c28eee46a5d6b13a7f8c5096c6efc1f603578c llvm-svn: 307287 2016-09-06T20:57:50+00:00 Kate Stone katherine.stone@apple.com 2016-09-06T20:57:50+00:00 urn:sha1:b9c1b51e45b845debb76d8658edabca70ca56079 *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751 2016-09-02T09:25:42+00:00 Pavel Labath labath@google.com 2016-09-02T09:25:42+00:00 urn:sha1:ce57a33e580daec47f09b21a46bed161aeb7dcc1 Still a bit flaky on remote targets. Trying a larger bump this time. :/ llvm-svn: 280477 2016-07-07T15:45:57+00:00 Pavel Labath labath@google.com 2016-07-07T15:45:57+00:00 urn:sha1:613cce835f1f8ed58a3f116ae979ee196ca826b8 remote targets need a bit more time to get their act together llvm-svn: 274762 2016-04-26T13:37:24+00:00 Pavel Labath labath@google.com 2016-04-26T13:37:24+00:00 urn:sha1:a24427533f16c173b2f6a4a6771b816db660c936 Expression very rarely (linux buildbot, build 13907) completed before we managed to interrupt it. llvm-svn: 267554 2016-04-01T18:42:45+00:00 Todd Fiala todd.fiala@gmail.com 2016-04-01T18:42:45+00:00 urn:sha1:3249911439295c56c256f1214c0d1a22c6cac5ff This test is failing on the CI but not locally for me. Needs investigation. tracked by: https://llvm.org/bugs/show_bug.cgi?id=27182 llvm-svn: 265175 2016-02-08T19:34:59+00:00 Zachary Turner zturner@google.com 2016-02-08T19:34:59+00:00 urn:sha1:4a289a93f733b9eafb85cd60dad7b0c24e2f51e4 expectedFailureWindows is equivalent to using the general expectedFailureAll decorator with oslist="windows". Additionally, by moving towards these common decorators we can solve the issue of having to support decorators that can be called with or without arguments. Once all decorators are always called with arguments, and this is enforced by design (because you can't specify the condition you're decorating for without passing an argument) the implementation of the decorators can become much simpler Differential Revision: http://reviews.llvm.org/D16936 llvm-svn: 260134