Marked XFAIL for:
clang - all versions < 3.5. I verified the first version it passes on Linux is 3.5.
clang - version 3.7 (verified this fails)
clang - TOT/3.8 (verified this currently fails)
Ideally we dig into why this started failing and (hopefully) get this passing again.
llvm-svn: 247664
Summary:
Linux with ToT clang (3.8) fails.
This reverts commit r247633.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12868
llvm-svn: 247648
Linux/clang on clang 3.6+ is passing this test. As OS X was
in a similar position, I'm guessing this was fixed by a recent
compiler. Might work on 3.5/3.4, but it is definitely working
on clang 3.6. I didn't break out FreeBSD since this appears to
be related to a compiler fix.
llvm-svn: 247633
TestPersistObjCPointeeType and TestObjCNewSyntax marked up to expect
success on clang >= 7.0.0.
TestMultipleDebuggers passed 25/25 times, taking off intermittent.
If this changes, I'll make sure it goes into a flaky/flakey category.
llvm-svn: 247601
Related to these two test case classes:
test/driver/batch_mode/TestBatchMode.py
test/functionalities/inferior-assert/TestInferiorAssert.py
llvm-svn: 247567
This test passes locally but was disabled due to pexpect issues on the
FreeBSD buildbot. That buildbot has been retired as it was overloaded,
and we will investigate again if this fails once a new buildbot is in
place. Noted by John Wolfe.
llvm.org/pr22784
This re-applies r247013.
llvm-svn: 247565
This test passes locally but was marked XFAIL due to failures on the
FreeBSD buildbot. That buildbot has been retired as it was overloaded,
and we will investigate again if this fails once a new buildbot is in
place.
llvm.org/pr23747
llvm-svn: 247562
This is a trivial issue to fix, just marking it for later.
Windows prints function signatures a bit differently, and the
test expects a specific format.
llvm-svn: 247457
This patch fixes the following case:
```
$ ./dotest.py --executable=~/p/llvm/build_ninja/bin/lldb tools/lldb-mi/
'~/p/llvm/build_ninja/bin/lldb' is not a path to a valid executable
Traceback (most recent call last):
File "./dotest.py", line 1306, in <module>
setupSysPath()
File "./dotest.py", line 1004, in setupSysPath
if not lldbtest_config.lldbExec:
AttributeError: 'module' object has no attribute 'lldbExec'
```
And with this fix:
```
$ ./dotest.py --executable=~/p/llvm/build_ninja/bin/lldb tools/lldb-mi/
'~/p/llvm/build_ninja/bin/lldb' is not a path to a valid executable
The 'lldb' executable cannot be located. Some of the tests may not be run as a result.
```
llvm-svn: 247256
It often hangs or times out, and obscures issues with other tests.
Just skip it for now (until the FreeBSD test suite is producing
consistent results) so that we can get a buildbot back.
Previous investigation (for failures) in llvm.org/pr18522
llvm-svn: 247190
We had 2 tests named TestCPPBreakpoints.py. If one of those tests
failed, both of them would be reported as failures and contribute
to the failure count. There may be other examples of duplicate
test names, and we should fix those as we find them.
llvm-svn: 247173
See https://llvm.org/bugs/show_bug.cgi?id=24708 for details.
Using '-f FILTER' or unnamed arguments (directories) to dotest.py
will now force no-multiprocessing mode. This stops a bombardment
of test output spam when following the instructions we provide
in a test session trace for rerunning the test.
llvm-svn: 247101
And update the comment describing the reason this test is skipped.
Unlike the issue described llvm.org/pr22784 this test sometimes causes
a hang on my local machine and is not just a problem on the retired
buildbot.
This reverts commit r247013.
llvm-svn: 247024
This test passes locally but was disabled due to pexpect issues on the
FreeBSD buildbot. That buildbot has been retired as it was overloaded,
and we will investigate again if this fails once a new buildbot is in
place. Noted by John Wolfe.
llvm.org/pr22784
llvm-svn: 247013
Summary:
- Bug 24457 can now be tested for inferiors compiled
by clang compiler also.
- A generic test case for GCC and Clang inferiors:
-- Works even when Clang and GCC produce different
assembly for the same inferior.
- Refer Differential Revision: http://reviews.llvm.org/D12677
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
llvm-svn: 247000
Summary:
For an array declared like "blk[2][3]", this command was showing:
-data-evaluate-expression blk
^done,value="{[0] = [3], [1] = [3]}"
After this fix, it shows:
-data-evaluate-expression blk
^done,value="{[0] = {[0] = 1, [1] = 2, [2] = 3}, [1] = {[0] = 4, [1] = 5, [2] = 6}}"
The code to do the right thing was already available and used by other commands.
So I have just used that and removed the half-baked previous implementation.
Reviewers: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12634
llvm-svn: 246965
Todd Fiala