*** 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
There were a number of problems preventing this from working:
1. The SWIG typemaps for converting Python lists to and from C++
arrays were not updated for Python 3. So they were doing things
like PyString_Check instead of using the PythonString from
PythonDataObjects.
2. ProcessLauncherWindows was ignoring the environment completely.
So any test that involved launching an inferior with any kind
of environment variable would have failed.
3. The test itself was using process.GetSTDOUT(), which isn't
implemented on Windows. So this was changed to save the
value of the environment variable in a local variable and
have the debugger look at the value of the variable.
llvm-svn: 257669
This patch fixes two issues:
1) Popen needs to be used with universal_newlines=True by default.
This elicits automatic decoding from bytes -> string in Py3,
and has no negative effects in other Py versions.
2) The swig typemaps for converting between string and (char*, int)
did not work correctly when the length of the string was 0,
indicating an error. In this case we would try to construct a
string from uninitialized data.
3) Ironically, the bug mentioned in #2 led to a test passing on
Windows that was actually broken, because the test was written
such that the assertion was never even getting checked, so it
passed by default. So we additionally fix this test to also
fail if the method errors. By fixing this test it's now broken
on Windows, so we also xfail it.
llvm-svn: 253487
They get treated as special RLE encoding symbols and packets get
corrupted. Most other packet types already know about this apparently,
but QEnvironment missed these two.
Should fix PR25300.
llvm-svn: 252521
This module was originally intended to be imported by top-level
scripts to be able to find the LLDB packages and third party
libraries. Packages themselves shouldn't need to import it,
because by the time it gets into the package, the top-level
script should have already done this. Indeed, it was just
adding the same values to sys.path multiple times, so this
patch is essentially no functional change.
To make sure it doesn't get re-introduced, we also delete the
`use_lldb_suite` module from `lldbsuite/test`, although the
original copy still remains in `lldb/test`
llvm-svn: 251963
For convenience, we had added the folder that dotest.py was in
to sys.path, so that we could easily write things like
`import lldbutil` from anywhere and any test. This introduces
a subtle problem when using Python's package system, because when
unittest2 imports a particular test suite, the test suite is detached
from the package. Thus, writing "import lldbutil" from dotest imports
it as part of the package, and writing the same line from a test
does a fresh import since the importing module was not part of
the same package.
The real way to fix this is to use absolute imports everywhere. Instead
of writing "import lldbutil", we need to write "import
lldbsuite.test.util". This patch fixes up that and all other similar
cases, and additionally removes the script directory from sys.path
to ensure that this can't happen again.
llvm-svn: 251886
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
