Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-09-04T07:46:25+00:00 2019-09-04T07:46:25+00:00 Pavel Labath pavel@labath.sk 2019-09-04T07:46:25+00:00 urn:sha1:418a272f4ab4221c37a9272d48fd31d5ac1bddc1 Summary: Instead of each test case knowing its depth relative to the test root, we can just have dotest add the folder containing Makefile.rules to the include path. This was motivated by r370616, though I have been wanting to do this ever since we moved to building tests out-of-tree. The only manually modified files in this patch are lldbinline.py and plugins/builder_base.py. The rest of the patch has been produced by this shell command: find . \( -name Makefile -o -name '*.mk' \) -exec sed --in-place -e '/LEVEL *:\?=/d' -e '1,2{/^$/d}' -e 's,\$(LEVEL)/,,' {} + Reviewers: teemperor, aprantl, espindola, jfb Subscribers: emaste, javed.absar, arichardson, christof, arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D67083 llvm-svn: 370845 2019-08-02T08:06:22+00:00 Raphael Isemann teemperor@gmail.com 2019-08-02T08:06:22+00:00 urn:sha1:9eedbc4f266d1e49d335d48c4c0f717401d927d2 llvm-svn: 367663 2019-01-19T08:50:56+00:00 Chandler Carruth chandlerc@gmail.com 2019-01-19T08:50:56+00:00 urn:sha1:2946cd701067404b99c39fb29dc9c74bd7193eb3 to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 2018-12-20T01:25:35+00:00 Stella Stamenova stilis@microsoft.com 2018-12-20T01:25:35+00:00 urn:sha1:92c129636115d1ab50ae4a2860b4450d04e3a09d This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green. llvm-svn: 349713 2018-01-19T23:24:35+00:00 Adrian Prantl aprantl@apple.com 2018-01-19T23:24:35+00:00 urn:sha1:595048f3ecf3317aa2d32bed5141a526415f5aea in TestBase::getBuildArtifact(). This NFC commit is in preparation for https://reviews.llvm.org/D42281 (compile the LLDB tests out-of-tree). Differential Revision: https://reviews.llvm.org/D42280 llvm-svn: 323007 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-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 2016-02-04T23:04:17+00:00 Zachary Turner zturner@google.com 2016-02-04T23:04:17+00:00 urn:sha1:9a1a2946affdfcefd7cd2e407f4dbf51082d597e llvm-svn: 259838 2016-01-22T23:05:47+00:00 Adrian McCarthy amccarth@google.com 2016-01-22T23:05:47+00:00 urn:sha1:bce5d9adce9d1964658c1ea2bf88de791a7e2523 Filed a bug to investigate later: llvm.org/pr26265 llvm-svn: 258578 2016-01-21T21:07:30+00:00 Zachary Turner zturner@google.com 2016-01-21T21:07:30+00:00 urn:sha1:783550be6211b65de45c4c44eac339311f3ae1e2 Starting with Windows 10, the Windows loader is itself multi-threaded, meaning that the loader spins up a few threads to do process initialization before it executes main. Windows delivers these notifications asynchronously and they can come out of order, so we can't be sure that the first thread we get a notification about is actually the zero'th thread. This patch fixes this by requesting the thread stopped at the breakpoint that was specified, rather than getting thread 0 and verifying that it is stopped at a breakpoint. Differential Revision: http://reviews.llvm.org/D16247 llvm-svn: 258432