This change addresses the corner case bug in the test
infrastructure where a test file times out *outside*
of any running test method. In those cases, the issue
was charged to the file, not to a test method within
the file. When that file is re-run successfully,
none of the test-method-level successes would clear
the file-level issue.
This change fixes that: for all test files that are
getting rerun (whether by being marked flaky or
via the --rerun-all-issues flag), file-level test
issues are searched for in each of those files. Each
file-level issue found in the rerun file list then
gets cleared.
A test of this feature is added to issue_verification,
using the technique there of moving the *.py.park file
to *.py to do an end-to-end validation.
This change also adds a .gitignore entry for pyenv
project-level files and fixes up a few minor pep8
formatting violations in files I touched.
Fixes:
llvm.org/pr27423
llvm-svn: 282990
Take 2, with missing cmake line fixed. Build tested on
Ubuntu 14.04 with clang-3.6.
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham
llvm-svn: 279202
for TestNamespaceLookup.py; didn't see anything obviously wrong so I'll
need to look at this more closely before re-committing. (passed OK on
macOS ;)
llvm-svn: 273531
There's uses of "macosx" that will be more tricky to
change, like in triples (e.g. "x86_64-apple-macosx10.11") -
for now I'm just updating source comments and strings printed
for humans.
llvm-svn: 273524
This change restores the Xcode build to working after Makefile support
was stripped from LLVM and clang recently.
With this change, the Xcode build now requires cmake (2.8.12.2+).
The cmake must either be on the path that Xcode sees, or it must
exist in one of the following locations:
* /usr/local/bin/cmake
* /opt/local/bin/cmake
* $HOME/bin/cmake
If the ninja build tool is present on the path, it will be used.
If not, ninja will be cloned (via git), bootstrap-built, and
used for the llvm/clang build.
LLDB now requires a minimum deployment target of OS X 10.9. Prior
to this, it was 10.8. The llvm/clang cmake build will not run
with Xcode 7.2 or Xcode 7.3 beta's compiler with the minimum
deployment target set to anything lower than 10.9. This is
related to #include <atomic>.
When llvm or clang source code does not exist in the lldb tree,
it will be cloned via git using http://llvm.org/git/{project}.git.
Previously it used SVN. If this causes any heartache, we can
make this smarter, autodetect an embedded svn and use svn instead.
(And/or use SVN if a git command is not available).
This change also fixes an lldb-mi linkage failure (needed
libncurses) as exposed by one of the LLVM libs.
llvm-svn: 259027
When running the test suite on Windows, we can't have Windows popping
up dialogs when LLDB crashes in native code because it will hang
the test suite. This patch silences those dialogs by checking an
environment variable at startup and configuring Windows based on
its value.
This patch also adds an environment variable to force inferiors to
never spawn in their own console window. This is useful to prevent
new window spawm when running the test suite.
Reviewed by: Scott Graham
Differential Revision: http://reviews.llvm.org/D6628
llvm-svn: 224137
This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).
Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.
The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64
Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id tfiala@google.com). I switched over to
user todd.fiala@gmail.com in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.
llvm-svn: 212069