| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
To the best of my understanding these files or their content is nowhere
referenced.
|
| |
|
|
|
|
|
| |
Tests that check the output of `memory find` may trip over
unreadable characters, and in Python 3 this is an error.
llvm-svn: 355612
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch finishes the python3-ification of the lldb-server test suite.
It reverts the partial attempt in r352709 to encode/decode the string
via utf8 before writing to the socket. This wasn't enough because the
gdb-remote protocol can sometimes (but not very often) carry binary
data, and the utf8 codec chokes on that. Instead I add utility functions
to the "seven" module for performing "identity" transformations on the
byte data. This basically drills back the hole in the python type system
that the string/bytes distinction was supposed to plug. That is not
ideal, but was the best solution of the alternatives I could come up
with. The options I considered were:
- make use of the type system to add type safety to the test suite: This
required making a lot of changes to the test suite, since most of the
strings would now become byte objects instead, and it was not even
fully clear to me where to draw the line. One extreme solution would
be to just use byte objects everywhere, as the protocol doesn't
support non-ascii characters anyway. However, this appeared to be:
a) weird, because most of the protocol actually deals with strings,
but we would have to prefix everything with 'b'
b) clunky, because the handling of the bytes objects is sufficiently
different in PY2 and PY3 (e.g. b'a'[0] is a string in PY2, but an
int in PY3).
- using the latin1 codec (which gives an identity transformation for the
first 256 code points of unicode) instead of the custom
bytes_to_string functions. This almost could work, but it was still
slightly different between python 2 and 3, because in PY2 in would
return a unicode object, which would then cause problems when
combined with regular strings if it contained 8-bit chars.
With this in mind, I think the best solution for the time being is to
just coerce everything into the string type as early as possible, and
have things proceed indentically on both python versions. Once we stop
supporting python3, we can revisit the idea of using bytes objects more
prevasively.
Reviewers: davide, zturner, serge-sans-paille
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D58177
llvm-svn: 354106
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When running the test suite on macOS with Python 3 we noticed a
difference in behavior between Python 2 and Python 3 for
seven.get_command_output. The output contained a newline with Python 3,
but not for Python 2. This resulted in an invalid SDK path passed to the
compiler.
Differential revision: https://reviews.llvm.org/D57275
llvm-svn: 352397
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
These happen in a couple of tests when lldb tries to pretty print a
const char * variable in the inferior which points to garbage. Instead,
we have the python replace the invalid sequences with the unicode
replacement character.
llvm-svn: 341274
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds the capability of building test inferiors
with the -gmodules flag to enable module debug info support.
Windows is excluded per @zturner.
Reviewers: granata.enrico, aprantl, zturner, labath
Subscribers: zturner, labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D19998
llvm-svn: 270848
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also does the following:
* adopts PEP8 naming convention for OptionalWith class (now
optional_with).
* moves test_runner/lldb_utils.py to lldbsuite/support/optional_with.py.
* packages tests in a subpackage of test_runner per recommendations in
http://the-hitchhikers-guide-to-packaging.readthedocs.org/en/latest/creation.html
Tests can be run from within pacakges/Python/lldbsuite/test via this
command:
python -m unittest discover test_runner
The primary cleanup this allows is avoiding the need to muck with the
PYTHONPATH variable from within the source files. This also aids some
of the static code checkers as they don't need to run code to determine
the proper python path.
llvm-svn: 266710
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This doesn't attempt to move every decorator. The reason for
this is that it requires touching every single test file to import
decorators.py. I would like to do this in a followup patch, but
in the interest of keeping the patches as bite-sized as possible,
I've only attempted to move the underlying common decorators first.
A few tests call these directly, so those tests are updated as part
of this patch.
llvm-svn: 259807
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch attempts to solve the Python 2 / Python 3 incompatibilities by
introducing a new `encoded_file` abstraction that we use instead of
`io.open()`. The problem with the builtin implementation of `io.open` is
that `read` and `write` accept and return `unicode` objects, which are not
always convenient to work with in Python 2. We solve this by making
`encoded_file.open()` return the same object returned by `io.open()` but
with hooked `read()` and `write()` methods. These hooked methods will
accept binary or text data, and conditionally convert what it gets to a
`unicode` object using the correct encoding. When calling `read()` it
also does any conversion necessary to convert the output back into the
native `string` type of the running python version.
Differential Revision: http://reviews.llvm.org/D16736
llvm-svn: 259379
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch, the client will package up all the required
inputs into a compressed zip file, establish a connection to the
server, send the input to the server, and wait for the server to
send a response (in this case the response is just echoed back to
the client).
This gets the network communication in place, and in a subsequent
patch I will follow up with the code that actually runs swig on
the server and sends back the output instead of echoing back the
input.
llvm-svn: 254023
|
| |
|
|
|
|
|
| |
I have plans to reuse this function in another script, so raising
this out of prepare_bindings allows this.
llvm-svn: 253755
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default in Python 3, check_output() returns a program's output as
an encoded byte sequence. This means it returns a Py3 `bytes` object,
which cannot be compared to a string since it's a different fundamental
type.
Although it might not be correct from a purist standpoint, from a
practical one we can assume that all output is encoded in the default
locale, in which case using universal_newlines=True will decode it
according to the current locale. Anyway, universal_newlines also
has the nice behavior that it converts \r\n to \n on Windows platforms
so this makes parsing code easier, should we need that. So it seems
like a win/win.
llvm-svn: 252025
|
| |
|
|
| |
llvm-svn: 251982
|
|
|
This file will be useful for filling in the gaps where `six` is
missing some things we need.
llvm-svn: 251847
|
