This is the conclusion of an effort to get LLDB's Python code
structured into a bona-fide Python package.  This has a number
of benefits, but most notably the ability to more easily share
Python code between different but related pieces of LLDB's Python
infrastructure (for example, `scripts` can now share code with
`test`).

llvm-svn: 251532

llvm-svn: 251444

Plural methods were long deprecated, and in Python 3 they are gone.
Convert to the actual supported method names.

llvm-svn: 251303

Summary:
Per discussions on the mailing list, I have implemented a decorator which annotates individual
test methods with categories. I have used this framework to replace the '-a' and '+a'
command-line switches (now '-G pyapi' and '--skip-category pyapi') and the @python_api_test
decorator (now @add_test_categories('pyapi')). The test suite now gives an error message
suggesting the new options if the user specifies the deprecated +/-a switches. If the general
direction is good, I will follow this up with other switches.

Reviewers: tberghammer, tfiala, granata.enrico, zturner

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D14020

llvm-svn: 251277

Apparently there were tons of instances I missed last time, I
guess I accidentally ran 2to3 non-recursively.  This should be
every occurrence of a print statement fixed to use a print function
as well as from __future__ import print_function being added to
every file.

After this patch print statements will stop working everywhere in
the test suite, and the print function should be used instead.

llvm-svn: 251121

Summary:
The list of loaded modules which skip_if_library_missing is depending on is not available on
linux until after we run the target. This causes the tests to be wrongfully skipped. This commit
moves the skip call after the run command.

Reviewers: granata.enrico, tfiala

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D13985

llvm-svn: 251102

This is necessary in order to allow third party modules to be
located under lldb/third_party rather than under the test
folder directly.

Since we're already touching every test file anyway, we also
go ahead and delete the unittest2 import and main block wherever
possible.  The ability to run a test as a standalone file has
already been broken for some time, and if we decide we want this
back, we should use unittest instead of unittest2.

A few places could not have the import of unittest2 removed,because
they depend on the unittest2.expectedFailure or skip decorators.
Removing all those was orthogonal in spirit to the purpose of this
CL, so the import of unittest2 remains in those files that were
using it for its test decorators.  Those can be addressed
separately.

llvm-svn: 251055

See http://reviews.llvm.org/D13964 for details.

llvm-svn: 250965

Summary:
Along with this, support for an optional argument to the "num_children"
method of a Python synthetic child provider has also been added. These have
been added with the following use case in mind:

Synthetic child providers currently have a method "has_children" and
"num_children". While the former is good enough to know if there are
children, it does not give any insight into how many children there are.
Though the latter serves this purpose, calculating the number for children
of a data structure could be an O(N) operation if the data structure has N
children. The new method added in this change provide a middle ground.
One can call GetNumChildren(K) to know if a child exists at an index K
which can be as large as the callers tolerance can be. If the caller wants
to know about children beyond K, it can make an other call with 2K. If the
synthetic child provider maintains state about it counting till K
previosly, then the next call is only an O(K) operation. Infact, all
calls made progressively with steps of K will be O(K) operations.

Reviewers: vharron, clayborg, granata.enrico

Subscribers: labath, lldb-commits

Differential Revision: http://reviews.llvm.org/D13778

llvm-svn: 250930

Summary:
Loop detection code is being called before every element access. Although it tries to cache some
of the data by remembering the loop-free initial segment, every time it needs to increase this
segment, it will start from scratch. For the typical usage pattern, where one accesses the
elements in order, the loop detection will need to be run after every access, resulting in
quadratic behavior. This behavior is noticable even for the default 255 element limit.

In this commit, I rewrite the algorithm to be truly incremental -- it maintains the state of its
loop-detection runners between calls, and reuses them when it needs to check another segment.
This way, each part of the list is scanned only once, resulting in linear behavior.

Also note that I have changed the operator== of ListEntry to do the comparison based on the
value() function (instead of relying on ValueObjectSP equality). In my experiments, I kept
getting different ValueObjectSPs when going through the same element twice.

Reviewers: granata.enrico

Subscribers: lldb-commits, sivachandra

Differential Revision: http://reviews.llvm.org/D13902

llvm-svn: 250890